Re^6: Any gotchas with CGI and Mouse running together?

[LanX]

> and it’s been “ejected” from Perl

yes but development has been resurrected.

> perlcc was fragile, difficult, and barely operative in many cases

sure but I'm not talking about individually precompling a users project, but offering Moose.pm (or whatever M*) itself in a precompiled version.

But I'm still not sure what "start-up time is slow" really means¹. For instance is dynamically requiring/evaling a module class using Moose fast after Moose has already been loaded?

If not precompiling wouldn't help. (like if the accessor syntax being the bottle neck or so)

update

¹) you say "Moose is expensive to use". But Is it only the first or every use which is expensive?

[Your Mother]

The startup time for a script using a ton of Moose classes can be a couple of seconds or even more. Some of my Catalyst applications take upwards of 30 seconds to start (not only Moose but it’s part of the slowness).

A couple of seconds is unbearably long for a command line utility you use a lot and totally irrelevant for a persistent webserver. After everything is setup (all the classes are composed and roles and attributes and all that) it’s decently fast but still something like 5x slower than Mouse for object use (a benchmark). I seriously doubt it can be precompiled sanely. Mouse took a lot of work and has a lot of hands on it and I think no one would have bothered if there were a(n easy) way to make Moose faster.

[LanX]

> After everything is setup (all the classes are composed and roles and attributes and all that)

so not only requiring and compiling Moose which is slow but composing new classes too. :-/

Tried installing it with cpanm and but it failed, though 47 dependencies were installed.

[Your Mother]

Yes, with “slow” being a slightly subjective term here. There are a few threads here and there discussing it better than I can.

[Anonymous Monk]

So LanX are you going to bench this?

[LanX]

Sounds like trolling ... :/

But let's take it positive, and try to make an insightful post worth linking to.

short

Your Mother already convinced me that startup time wouldn't improve much and I'm not a M* user anyway.

So why don't you bench it? :)

long

FWIW some theory for those interested:

The famous "startup time using Moose" actually consists of at least 3 phases, cause in reality Moose is used in every single class involved ¹:

1. Compilation:

   require of Moose.pm at first use Moose;

2. Exporting:

   calling Moose->import() for each use Moose;

3. Application:

   calling exported Moose::subs() sugar like has in each class during their use Class;

Naturally pre-compilation (like "perlcc Moose") can only effect phase 1, which is a one-time advantage.

But YM already pointed out that startup time grows significantly with the number of classes.

conclusion

If you or anyone else is interested in benchmarking it, I'd suggest taking Schwern's test scenario and extend it appropriately to identify these phases.

¹) so what people actually mean is the resulting start up time of modules/classes build with Moose.

update

Of course one could try to benchmark the application of classes created with Moose, i.e. mainly creating objects and calling methods.

But that's not startup time anymore, and hearsay is that runtime is fast enough.

[Anonymous Monk]

Sounds like trolling ... :/

Really? Sad

Simple yes or no question ... you seemed really really interested, and I know you like to test, so I was wondering if you were planning on doing it ... if i should bookmark this node or not