Re: Re: Re: Moose Or No Moose

This has been a crazy week here in Moose-land as you might have read. I would like to attempt to sum this all up so that we can all move on and get back to programming (which is sooooooo much more fun then blogging).

Adam Kennedy responded to all this in his recent use.perl post, and then later came into the #moose IRC channel to discuss. In that post I think that he did an excellent job of answering the "Should Padre use Moose" question. His conclusion seemed to be "Not Yet" which I can respect given his well thought out reasons. I was also happy to see that Adam felt Moose had the "air of inevitability" about it, and he felt it was only a matter of time till the Moose community solved our startup time and memory efficiency issues.

For the record, I was never actually suggesting that Padre should immediately be re-written in Moose, but more that Padre and Moose might benefit from one another, and would those benefits perhaps outweigh the costs. For Adam (and I assume the rest of the Padre team) the answer was "Not Yet", that the costs were too high and that benefits not compelling enough for them.

Then this morning I arrived at my desk to see Daisuke Maki had posted his 2 cents about this debate. Two lines in Daisuke's post jumped out at me. The first was this one:

I'd really like them [the Moose develoers] to make a more thought-out response, and act like you actually care about the parties involved that have a slightly different view than yours

And the second was:

That will make my life easier. I can point people to the Moose roadmap or whatever and say, "look, they care. they /will/ address your concerns. let's just install Moose in your system for now, yeah?" and go on hacking with Moose.

So while I don't have any official roapmap yet, I will say that "we are working on it" and "we do care". If nothing more, this recent debate has served to light a fire under the Moose development team and forced us to take a closer look at ourselves. It is a challenge and one that we are ready to take on.

The first step is to admit that you have a problem.

So last night (after a challenge from Adam on IRC) Jesse (doy) Luehrs added memory usage stats to Shawn (Sartak) Moore's original script which produced this data and then Cory (gphat) Watson used his Chart::Clicker module, which is written in Moose ;) to produce this graph:

The purple line is startup time and the yellow line is memory usage. (As I pointed out before, that nice downward drop at the very end there is a direct result of the Japan Perl Associations sponsorship of Goro Fuji).

The second step is to do something about it.

A big part of the memory and CPU hit is from the meta-layer. These are all the objects that Moose has to create for your class, and then all the code Moose compiles and evals to make sure things are fast at runtime. This is largely a one-time (compile time) cost and if you never call the "meta" method on your Moose class then you never use it again. We currently have two projects going on to help reduce or even eliminate some of these costs.

A recent post by fREW Schmidt announced that he is currently working to refactor the Moose test suite in such a way that the meta-level tests are optional. This is to help make way for Matt Trout's proposed "Antlers" project, which aims to "compile" Moose classes such that the meta-layer (the part that consumes most of the memory and takes so much time at startup) is not loaded or used unless you actually specifically request it by calling the "meta" method itself.

This idea has been kicking around the Moose team's heads for a while, in fact it is an evolution/mutation of Yuval Kogman's MooseX::Compile module. When Yuval wrote his version over a year and a half ago, Moose did not have the proper features internally and so the project was shelved. Now we feel that Moose is ready, and with fREW's test suite refactoring, it should only be a matter of tuits before this can become a reality.

The second is a combination of Goro Fuji's work and some XS-ification that Yuval Kogman, Florian (rafl) Ragwitz and a few other Moose hackers have been doing. The aim of this is to eliminate much of the need to do the code evaling for accessor and constructor generation by moving them to XS. Since we don't want you to pay for any more features then your using, Moose currently will compile only as much accessor and constructor code as you need and eval it into existence (which gets expensive). It is the hope that by moving that code to XS we can eliminate the speed penalty of un-used features and therefore not need to custom compile anymore.

The third step is to recruit new cult members.

Actually I am not sure if that is the 3rd step or not, but it sounds good to me. So if you love Moose and have some spare tuits lying around, please come and help pick some low hanging fruits and make this a reality.