Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of markjugg (792)

Monday December 01, 2008
06:08 PM

HTTP::Engine drops Moose for Shika, gains massive speedup

[ #37998 ]
When I recently benchmarked several Perl website development tools, HTTP::Engine had dismal performance. The slowest performer, it took 1.5 seconds just to print "Hello World" in a CGI environment and took 14.6 megs of memory to it.

Today the first HTTP::Engine release appeared that replaces Moose with Shika. Shika provides the essential class-building tools that HTTP::Engine needs with a Moose-compatible syntax, and strips out the rest of the magic.

The performance improvement was dramatic. The "Hello World" time dropped to 0.19seconds on the same hardware (almost 10 times as fast!) and the memory usage dropped to 6.6 Megs.

Catalyst is currently slated to use Moose in the next major version. Now that HTTP::Engine has switched away from Moose for better performance and memory savings, will other projects follow suit?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I wonder what would've happened if Mouse was tried first.

  • ... CGI performance is irrelevant, since nobody uses CGI anymore. Modern Perl trades compile-time speed for runtime speed. If you think it's a good idea to recompile your application every time there is a web request, then you should probably not use Catalyst or HTTP::Engine.

    FWIW, Shika is being rolled into Mouse, which means HTTP::Engine will soon be both fast and easily compatible with Moose and Moose extensions... and every other user of Moose/Mouse gets that speed for free!

    • Really? I use Perl in a CGI environment all the time because that is all that is available to me at work and it is cheap (and I do small sites) with hosting providers.

      Is there a cheap mod_perl hosting site?

    • Oh...but I agree I wouldn't use Catalyst for a CGI site because that isn't what it is designed for. I use CGI::Application and I may be trying Mojo very soon as well.

    • ... CGI performance is irrelevant, since nobody uses CGI anymore..

      That's just BS. I use vanilla CGI plenty, and it has never been the source of declaring that an application was too slow or otherwise inappropriate technology. I back up the benefits of vanilla CGI [stosberg.com] specific details on hosting availability and expected performance limits where CGI quits being a good choice.

      I totally agree that Catalyst apps would run too slow in vanilla CGI, but Catalyst alone does not define "modern Perl".

      Even Catalyst's new

      • Mojo runs decently in CGI with many of the same features.

        The features aren't really the same. Try doing something like Some::Role->meta->apply( $c->request ). A lot of Moose (and Catalyst) imitators steal the sugar, but the sugar is not the power... the internal consistency and extensibility is.

        Anyway, doesn't matter much if all you want to do is get some crap out of a database and add some HTML tags around it. TMTOWTDI.

        • If someone wants to start with a lighter-weight framework and use it combination with Moose, they are quite welcome to. DayDayUp [cpan.org] is Mojo-based, and also brings in Moose.

          However, there's no way to use the new Catalyst without Moose, if you don't want the overhead of loading Moose feature which won't be used.

  • What’s the use of HTTP::Engine when you’re running under CGI anyway? Might as well cut out the middle men and just use CGI::Simple. At least then you have no worries about latency.

    It doesn’t provide a sensible upgrade path anyway, since engineering for minimal startup time is so different from engineering for a persistent environment. You don’t want to just take a CGI script verbatim and run it as a server, even if that script happens to be written against HTTP::Engine.

    • I think a "use case" might be something like Movable Type. When they distribute it, they don't know ahead of time whether it will be deployed in CGI, FastCGI, or mod_perl, so they code it work in all three, and could HTTP::Engine to abstract which backend is in use.

      I actually use Movable Type in CGI because it was easy to deploy that way, and nearly all the public parts are rendered as static HTML. The admin interface is a bit slow, but I'm not the only user and it's fast enough for me.

      Currently the Movable