Re^3: Modern Perl Programming Highs and Lows

we hope by the end of this year to have completely removed the need for it to exist at all.

Can you elaborate on what need you see for it to exist and how you aim to remove it? Depending on how you define the terms, this statement could mean anything from "we're working to improve Moose's speed" to "Moose is replacing blessed hashes in /usr/bin/perl".

Comment on Re^3: Modern Perl Programming Highs and Lows

Replies are listed 'Best First'.
Re^4: Modern Perl Programming Highs and Lows by stvn (Monsignor) on Apr 29, 2009 at 17:56 UTC
Can you elaborate on what need you see for it to exist and how you aim to remove it? Mouse exists because Sartak wanted to use Moose for a command line program that needed to start up fast. Moose has a well known issue with startup time, so it just was not an option in this case. So Sartak pulled out a Moose-clone he was playing around with (to help learn how Moose worked he says) and so Mouse was born. It needs to exist for situations like this, where Moose is just not capable of fitting. We aim to remove the need for Mouse by fixing the issues in Moose that Mouse addresses. Matt Trout, Yuval Kogman, Florian Ragwitz and others spent a fair portion of the Nordic Perl Workshop refactoring the Moose internals to make way for Matt's Antlers project. Antlers plans to cache all meta-objects that Moose creates as well as all the accessor code generation that Moose does. Then only load up the meta-object when absolutely necessary. This should result in a faster startup time because of less CPU usage and then less memory usage overall (unless you call ->meta, in which case then you will need to load that meta-object). Florian and Yuval are also working on another project called Moose::XS which will replace much of the generated accessors (all perl code that must get string-evaled (big performance hit there)) with leaner XS versions. This alone should go a long ways to reducing the startup speed (less string-eval means less CPU) and should help some with memory (the core accessors can be re-used rather then having to eval a new method into life each time). These projects are still in the early stages, but they are based on research we have been doing for well over a year now so we are pretty confident in them. Hopefully much progress will be made at the various conference hackathons this year and (as I said above) we hope to have something working and ready for production use by years end (I would say christmas, but perl 6 has already taken that). -stvn	[reply]

Replies are listed 'Best First'.

Re^4: Modern Perl Programming Highs and Lows
by stvn (Monsignor) on Apr 29, 2009 at 17:56 UTC

Can you elaborate on what need you see for it to exist and how you aim to remove it?

Mouse exists because Sartak wanted to use Moose for a command line program that needed to start up fast. Moose has a well known issue with startup time, so it just was not an option in this case. So Sartak pulled out a Moose-clone he was playing around with (to help learn how Moose worked he says) and so Mouse was born. It needs to exist for situations like this, where Moose is just not capable of fitting.

We aim to remove the need for Mouse by fixing the issues in Moose that Mouse addresses. Matt Trout, Yuval Kogman, Florian Ragwitz and others spent a fair portion of the Nordic Perl Workshop refactoring the Moose internals to make way for Matt's Antlers project. Antlers plans to cache all meta-objects that Moose creates as well as all the accessor code generation that Moose does. Then only load up the meta-object when absolutely necessary. This should result in a faster startup time because of less CPU usage and then less memory usage overall (unless you call ->meta, in which case then you will need to load that meta-object). Florian and Yuval are also working on another project called Moose::XS which will replace much of the generated accessors (all perl code that must get string-evaled (big performance hit there)) with leaner XS versions. This alone should go a long ways to reducing the startup speed (less string-eval means less CPU) and should help some with memory (the core accessors can be re-used rather then having to eval a new method into life each time).

These projects are still in the early stages, but they are based on research we have been doing for well over a year now so we are pretty confident in them. Hopefully much progress will be made at the various conference hackathons this year and (as I said above) we hope to have something working and ready for production use by years end (I would say christmas, but perl 6 has already taken that).

-stvn

[reply]