Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

object oriented performance

by burn8 (Acolyte)
on Jul 16, 2005 at 15:42 UTC ( [id://475463]=perlquestion: print w/replies, xml ) Need Help??

burn8 has asked for the wisdom of the Perl Monks concerning the following question:

I once had a professor state that using the object oriented functionality in Perl would introduce a performance hit of approximately 30%. Is or was this ever true? If true, what is the reason for the reduction in performance? -burn8

Replies are listed 'Best First'.
Re: object oriented performance
by davido (Cardinal) on Jul 16, 2005 at 16:20 UTC

    There is some overhead associated with object oriented designs in Perl. The easiest to explain is the fact that objects are usually based on hashes, and hash lookups have a little overhead associated with them. Autoloading can also take a little time, inheritance tree searches take time, and so on. How much overhead OO adds depends on a lot of factors, and 30% is a pretty broad generalization. 30% as compared to what? Non OO designs will have their own complexities and own issues to deal with too. But yes, there is some performance hit.

    The bigger question is do you care? If an OO design is the right design from a programming and maintainability standpoint, use it unless you can actually demonstrate that you've got a performance bottleneck that is significant enough to be concerned with. Chances are that if you've got code that's not meeting its performance requirements you've got the wrong algorithms or the wrong approach to a problem. You won't know until/unless you profile your code. Use/test your code. Then if necessary profile it. Then if necessary optimize it where the profiler tells you to direct your efforts. We all know what they say about premature optimization being one of the basic evils of the universe. ;)


Re: object oriented performance
by davebaker (Pilgrim) on Jul 17, 2005 at 01:42 UTC
    From the Preface to Dr. Conway's book, Object Oriented Perl:
    A single method call is about 30 percent slower than a regular call to the same subroutine (depending on your hardware, your operating system, the phase of the moon, etc.) But though they're individually much slower, method calls are more powerful than regular subrotine calls, due to a feature known as polymorphism (see chapters 1 and 7). In a larger system, that redresses the speed imbalance in a little [sic], but in general, it's fair to say that an object-oriented implementation of a system in Perl will almost never be faster than the equivalent non-object-oriented implementation, and will usually be somewhere between 20 to 50 percent slower."

    But, he goes on to say, there are many compensating benefits, and he then lists them.

    I just got the book today-- it looks terrific!

    Published by Manning Publications Co. (, but I got mine through (click) for only $28.50 -- 34% off the cover price. I love that outfit.

      A single method call is about 30 percent slower than a regular call to the same subroutine

      These days the performance hit for method calls is around 10-15%. I imagine that the caching of method lookups has got better over time.

      use strict; use warnings; use Benchmark qw( cmpthese ); { package Foo; sub new { bless {}, shift } sub self { $_[0] } } my $o = Foo->new; cmpthese(-1, { subroutine => sub { my $o = Foo::self( $o ) }, method => sub { my $o = $o->self }, }); __END__ # perl 5.8.7 on my box gives... Rate method subroutine method 579231/s -- -10% subroutine 643109/s 11% --
Re: object oriented performance
by brian_d_foy (Abbot) on Jul 16, 2005 at 17:52 UTC

    There is some sort of performance hit because perl has to do more, but it's not as if everything in your program all of a sudden takes a lot longer. Other things don't get slower. Most interesting programs have their performance limited by something else such as network latency, database interactions, or beefy computations.

    brian d foy <>
Re: object oriented performance
by mdxi (Beadle) on Jul 17, 2005 at 09:53 UTC
    A bit of perspective from the The-More-Things-Change Dept:
    Computers today are much faster and less expensive than they were only a few short years ago, and continued improvements in both speed and cost are anticipated in the future. Although one can argue that {OO methodologies} have saved work for programmers while making extra work for computers, the difficulties of {languages without OO} have convinced most computer users that the use of {object orientation} is economically justified.
    This is a redacted quote from Programming the IBM 1130 and 1800, published in 1967. To get the original, just replace the {oo} bits with compiled languages and the {non-oo} part with assembler :)
Re: object oriented performance
by kimanaw (Beadle) on Jul 16, 2005 at 23:51 UTC
    Some overhead, yes. 30% ? Not likely, unless you subscribe to the notion "each method should only be <tiny-number> lines long", which would mean the overhead of each method call is a significant piece of the total RTT.

    Also note that its possible to use arrayrefs for your objects, tho you should only use that for "final" classes. Last time I ran a comparison test, arrayref objects were almost 4x faster than hashref objects (assuming the called methods are just stubs).

    Update: Ooops!Just recalled, the arrayref tests included member references, I believe thats where the biggest improvement between arrayref v. hashref objects shows up...

      Are you willing to share this test code?
Re: object oriented performance
by pg (Canon) on Jul 17, 2005 at 04:12 UTC

    This is a general issue higher than Perl. If you look at c and Java. c is much faster, although Java is getting faster over the years. But more and more people are now using Java, as it provides many benefits that c cannot. Just like other situations in life, there is taken and given you have to weigh.

      Noooo not Java..

      If someone is desperate enough to use object orientation to jump from C, then C++ would be a natural progression.

      Java and C, however, aren't really red apples and green apples.. ie the comparison between the two isn't really fair.

      Yes, C++ will slow down a wee bit, but going to Java is like going from flying aircraft to getting on a bicycle.. less chance of a major crash but much much slower..

Re: object oriented performance
by nothingmuch (Priest) on Jul 17, 2005 at 06:41 UTC
    Maybe. But why do you care?

    If you want fast OO, or fast whatever, use C/C++, or even assembler... Perl is about taking away your headache, not about performance.

    zz zZ Z Z #!perl
Re: object oriented performance
by schwern (Scribe) on Jul 18, 2005 at 06:02 UTC

    I wonder at the context of your professor's statement. Was it offhand or was he trying to make a point? Though I must say I'm happy OO Perl is even known to exist in most universities.

    Computer science teachers tend to over emphesize code speed a wee bit too much.

Re: object oriented performance
by jacques (Priest) on Jul 17, 2005 at 02:52 UTC
    Sounds like your professor was just trying to demean Perl. Yes, there's a performance hit. But many times there are other things that are slowing down your program, usually the least of which would be Perl itself.

      You didn't follow his question.

      His professor was comparing Perl and OO-Perl - two different approaches of coding in Perl, not comparing Perl with some other languages. In this case, the "other things" you mentioned are most likely cannot be used as reasons.

        You didn't follow his question.

        And you didn't follow my reply.

        I never said the professor was comparing Perl to other languages.

      Sounds like your professor was just trying to demean Perl

      I can't see how stating facts (or close approximations thereof) is demeaning.

        He exluded the fact that sub calls and oo calls are almost never higher than 5% of total runtime of an app (unless you have some very tight loops that were not unwound to deal with the slowness of both). So he implied that oo-perl was 30% slower ehn in fact it is usuqally a few percent slower in a real app.

        I can't see how stating facts (or close approximations thereof) is demeaning.

        It depends on how you say it and the context. And I never said he was being demeaning.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://475463]
Approved by davido
Front-paged by GrandFather
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (2)
As of 2024-06-23 07:50 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.