develooper Front page | perl.perl5.porters | Postings from September 2012

Perl::Formance numbers (was: What is Perl being optimized for?)

Steffen Schwigon
September 12, 2012 13:30
Perl::Formance numbers (was: What is Perl being optimized for?)
Message ID:
Paul Johnson <> writes:
> On Tue, Sep 11, 2012 at 07:57:39AM -0400, Peter Rabbitson wrote:
>> On Tue, Sep 11, 2012 at 01:30:54PM +0200, Johan Vromans wrote:
>> > Peter Rabbitson <> writes:
>> > 
>> > > We have by a huge margin the largest function invocation overhead
>> > > compared to other dynamic languages.
>> > 
>> > May I assume this in one of Perl's top priority issues to be fixed?
>> > 
>> Any time I bring this up with the elders in casual discussions I get
>> a "Yeaaah... it is a problem, we should investigate. Wanna take a
>> look?"
>> And of course nothing happens because I don't know enough C to save
>> my life, nor have the time/resources to engage in a crash-course in
>> Perl internals.
>> But yes, the function invocation speed problem is very real. If
>> anything we are getting even slower on this front with time, I am
>> sure Steffen Schwigon has actual data to back me up.
> Posting (a link to) that data would be a really good start.
> If nothing else it would prove that there is actually a problem to be
> solved and would give a target to aim at.  Then someone light feel
> like taking up the challenge.


Good first overview:

My function call benchmarks do naive fibonacci numbers via recursion.

I have many variants: plain function calls, and several method call
variants (selfmade/Moose/Mouse/MXDeclare).

 *          - plain Perl subs
 *        - selfmade OO
 *     - Moose OO
 * - MooseX::Declare


 * fib (plain subs) in Perl is ~2500x slower than symmetric
   implementation with C

    - C comparison not part of Perl::Formance, done separately

 * fibOO (selfmade/Moose/Mouse) is ~1.5x slower than plain subs

 * fibMXDeclare is about ~500x times slower than plain subs.

    - yes, that's 1.2 million times slower than C, sorry.

    - but probably due to some follow-up effects like huge mem triggering
      swapping or similar

    - anyway, the number itself is not an artifact or mistake, it's
      stable over different Perl versions, it's a complete mess,
      therefore I don't run it often

Trends, still fibonacci:

 * Perl 5.10 to 5.14 improved a runtime of 90s down to 76s.

 * Perl 5.16 deteriorated back to ~90s runtime.

 * The overhead of "threaded" over "non-threaded" 

   ... was in 5.10 ~5% more time
   ... got worse in 5.12 to ~15% more time
   ... improved in 5.14 to nearly zero 
   ... and is now back worse in 5.16 with ~20% more time

 * I do't have conclusive 5.17.x numbers due to current issues[1], but
   first experiments seem to indicate a trend towards more slowness.

Kind regards,

PS: Kudos to Peter Rabbitson for daring to be Yet Another Reini.
    Keep the faith, there is a Reini inside all of us. :-)

[1]  Perl 5.17 breaks several CPAN modules which triggered need for
     better error handling in Perl::Formance which I fixed but need to
     finish my Pinto work needed to inject that into a stable CPAN
     mirror. I'm in the muddle of it...

     I also have to redo 5.8 and 5.9, it's on my TODO list but not easy.
Steffen Schwigon <>
Perl benchmarks <>
Dresden Perl Mongers <> Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About