|
Lexicon has asked for the wisdom of the Perl Monks concerning the following question:
I have a module which has to maintain an internal state, and would be a good canditate for OOPLing. However, it is a Math Module, and I don't want to sacrifice too much speed. I havn't been able to find any online tutorials which give much text to efficient objects so I thought I'd ask a few directed questions here:
- Is OOP always significantly slower than procedural?
- By how much?
- Are there some special traps to be avoided?
- Are there special techniques to erase the problems?
- etc...
And yes, I know, "Go buy the Object Oriented Perl book." I think we can provide something a little more convenient and cheaper than that alternative. I think, optimally, a nice little Tutorial would be best. *hinthint* ;-)
-Lexicon |
Re: Object Oriented Perfomance
by Rhandom (Curate) on Apr 23, 2001 at 17:57 UTC
|
Use the Benchmark module. It will let you know relative speeds.
From what I've tested, method calls are around 20% slower. So, the question for your stuff is, do you need inheritance. If you do, then that answers it easily. Are your calls (to either function or method) in a tight loop (are there many iterations). If not, then again, the OOP might not be that bad (if it only takes one method call to get the whole thing rolling and you don't use the method calls after that, then by all means use OOP).
Another thing to consider is that if you are not using inheritance you can do things like this.
my $obj = MyObj->new( 'blah' );
while( 1 ){
my @args = qw( 'blah' );
&MyObj::my_method( $obj, @args );
}
When inheritance is not involved $obj->my_method( @args ); is the same as &MyObj::my_method( $obj, @args );. The only difference is speed.
my @a=qw(random brilliant braindead); print $a[rand(@a)]; | [reply]
[d/l]
[select] |
|
|
So, the question for your stuff is, do you need inheritance.
When deciding on whether to use OO, inheritance is never in my the calculations and performance rarely is. In Perl at least, the main reason to use OO is that you need more than one "object", that is, a collection of data that you define some operations on. If you need more than one collection of data and more than one operation (especially if the number of operations is large or likely to grow), then OO is a good choice.
You can do inheritance via Exporter.pm, using closures, or AUTOLOAD (to name a few), with or without the ability to create objects.
-
tye
(but my friends call me "Tye")
| [reply] |
Re: Object Oriented Perfomance
by Mungbeans (Pilgrim) on Apr 23, 2001 at 13:37 UTC
|
What are you doing? How much of it is there?
Unless it is a huge volume of transactions I don't think you'll notice any hits. Of course if you want to do some testing and let us know the results I'd be fascinated.
If it is high volume, and performance is key then maybe you're better doing it in C.
| [reply] |
(dws)Re: Object Oriented Perfomance
by dws (Chancellor) on Apr 23, 2001 at 22:08 UTC
|
Is OOP always significantly slower than procedural?
Back when I was working on Smalltalk at ParcPlace, we had a saying about Smalltalk that can also be applied to using Objects with Perl:
Smalltalk: A little slower, but a lot sooner.
The point being that the leverage gained from having a well tested class hierarchy (think CPAN) to build on usually wins out over the perceived need to make the code as fast as possible.
Method invocation is 15-20% slower than static function invocation, but performance bottlenecks tend to cluster into small sections of code, allowing selective optimization. If you're up to speed on objects, you'll get to the bottlenecks quicker, and will have more time to profile and optimize.
| [reply] |
Re: Object Oriented Perfomance
by stephen (Priest) on Apr 23, 2001 at 22:24 UTC
|
Object Oriented Perl will say more about this subject than any of our posts or any known online documentation.
That being said, you should also check out the 'use fields' module. One of the bigger slowdowns for working with class modules is that most of them (for good reason) are based on hashes. The fields module lets you use pseudo-hashes instead. Pseudo-hashes look pretty much like normal hash references, but internally they're arrays, so they give faster access. Plus, using fields gives you better error-checking on field names, since a pseudo-hash'll raise an exception on a misspelled key.
stephen
| [reply] |
Re: Object Oriented Perfomance
by petdance (Parson) on Apr 23, 2001 at 17:38 UTC
|
Well, you've got perldoc perltoot to start with.
I really don't understand why people are so loathe to shell
out a few bucks for their education. We're talking $40 to
get Damian's book, easily the best computer book I've read
in a while, and what has become the standard OO Perl text.
I mean, we're professionals here, right? Spend a few bucks
in the name of education.
xoxo,
Andy
# Andy Lester http://www.petdance.com AIM:petdance
%_=split';','.; Perl ;@;st a;m;ker;p;not;o;hac;t;her;y;ju';
print map $_{$_}, split //,
'andy@petdance.com'
| [reply] |
|
|
I'm not sure if Lexicon can get it for that cheap. You're thinking in US terms, and he's not in the US currently.
ALL HAIL BRAK!!!
| [reply] |
|
|
Side note: Technical books actually cost less in some non-US places. And there's stuff available outside of the US that can't be found here, such as one of my prized possessions: Knuth in paperback, obtained by a friend in the UK.
| [reply] |
|
|
Here in Iceland, Damiens book retails for about 6-7000 IKR which is about 60-70 USD.
| [reply] |
|
|
It would help if you told him the name of the book
before attacking him for not buying it. Maybe he's never
heard of the book, which sounds like a good reason to ask
up here.
Here is the PerlMonks book review of Object Oriented Perl
It's not published by O'Reilly, so he may never have found it ;^}
| [reply] |
|
|
It would help if you told him the name of the book before attacking him for not buying it. Maybe he's never heard of the book,
which sounds like a good reason to ask up here.
This proves not to be the case.
He's well aware of
the book in question. Check the small italic
section at the end of the post. What I took issue with
was that he seemed aghast at the notion of paying for
information, especially when the book explicitly covers
all of his concerns.
xoxo,
Andy
# Andy Lester http://www.petdance.com AIM:petdance
%_=split';','.; Perl ;@;st a;m;ker;p;not;o;hac;t;her;y;ju';
print map $_{$_}, split //,
'andy@petdance.com'
| [reply] |
|
|
|
|
