in reply to Re^2: Any gotchas with CGI and Mouse running together?
in thread Any gotchas with CGI and Mouse running together?

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.

  • Comment on Re^3: Any gotchas with CGI and Mouse running together?

Replies are listed 'Best First'.
Re^4: Any gotchas with CGI and Mouse running together?
by LanX (Saint) on Feb 27, 2015 at 04:30 UTC
    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!

[reply]
[d/l]

      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.

[reply]
[d/l]
        > 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)

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

        PS: Je suis Charlie!

        update

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

[reply]

In Section Seekers of Perl Wisdom