I don’t think it’s silly. The Mouse is precompiled essentially being XS (when built with it). I expected it to be faster actually but regular old Perl often surprises me with how fast it is. I tend to forget that most of why stuff at work is slow is awful DB code and not just the awful Perl we have. :P Doing thousands of objects and methods would probably make the Mouse a clear winner. So it would depend on how big/complex the code chains will end up.

Start up time is only a (serious) issue if running plain CGI as executables; which is a terrible way to do things but still the easiest. Our codebase at work is 50% legacy CGI that was finally taking 3 seconds to return simple pages—code bloat and universal loading of all the libs we have. Making it persistent (pre-compiled by a master server) fixed (most of the outward perception of) that.

Thx, already up-voted after the first phrase! ;)

But let me rephrase: for various reasons I never got sufficiently well into any of those /M[eosu]+\.pm/ animals.

I always read that even a simple use case of Moose has a notable startup penalty, but its not applying Moose to create objects and classes which is slow.

Hence should Moose itself have a costly compilation/ BEGIN phase when used.

At the same time perlcc is praised for its ability to precompile code to a static OP-tree.

So either it should be possible to precompile Moose to fast OP-code-image or something is wrong in my understanding.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

PS: Je suis Charlie!

I don’t actually know about this at all. I never used it but was under the impression that perlcc was fragile, difficult, and barely operative in many cases; and it’s been “ejected” from Perl: What happened to perlcc?. Moose is expensive to use. That was the impetus for Mouse. Moose is, for most/most users, too slow for command line tools and such.