Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of Stevan (6065)

Friday December 14, 2007
05:10 PM

Moose 2x Speed-Up

[ #35102 ]

One of the biggest complaints/problems with Moose has always been it's compile time cost. Well with the newest release of Moose (0.33) and Class::MOP (0.49) we have made a major step towards reducing that. With judicious use of XS (konobi++ for that) and some caching in key parts of Class::MOP we have managed to cut Moose load time almost in half, here are the stats from my machine (MacBook Pro w/ 2.4 GHz Intel Core 2 Duo).

Moose 0.32 & Class::MOP 0.48 => 0.46 real 0.43 user 0.02 sys
Moose 0.33 & Class::MOP 0.49 => 0.27 real 0.22 user 0.02 sys

This change also brings allowed us to take advantage of some 5.10 specific improvements as well. In 5.8.* we use the PL_sub_generation interpreter global to determine when to invalidate our method cache, which was one of the big parts of the speed win. In 5.8.* this is incremented every time a package is changed, which means we were probably invalidating our cache even when we didn't need to. Now in 5.10 we are using the mro::get_pkg_gen function, which provides the same feature but increments on a per-package basis, which means less incorrect cache invalidation.

All in all, not bad for a few hours of work by the folks on #moose.

- Stevan

NOTE: I got my stats wrong in the ChangeLogs, I called it a ~45% speed increase, but it is really 45% less slow.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Come now, we agreed in IRC that the correct way to express the difference was 63% more fastyness.
  • That's really cool. I'm starting to use Moose in some of my applications, but still hesitate using it in CGI (non-FastCGI) scripts, due to that +- 0.20 secs overhead which is still very heavy. Anyway, keep up the great work!
    • A major reason for this recent efforts to cut startup time is actually because we are working with Max Kanat-Alexander (of Bugzilla [everythingsolved.com] fame) to try and get Moose fast enough to be used in the refactoring/rewriting of Bugzilla. Max is already a fan of Moose and has used it on his (very cool) "All your VCS are belong to us" module VCI [cpan.org] module. I suspect that by mid-spring you will be able to deploy Moose apps under vanilla-CGI without a worry.

      - Stevan

  • This looks like a good start, keep the fastyness improvements coming.

    Then maybe one day Moose::Tiny may actually be able to compete with Object::Tiny :)
    • Well, we will never beat you on memory usage, but I feel I must remind you that Moose::Tiny is 8% shorter to type than Object::Tiny ;)

      Also, we are really breathing down your neck with our accessors (from the Moose::Tiny POD):

        Benchmarking accessors...
                 Rate moose  tiny
          moose 485/s    --  -19%
          tiny  599/s   23%    --

      And reallly, the difference in speed here is simply because Moose::Tiny c