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?
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!
Re:Of course...
sigzero on 2008-12-02T13:17:14
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?
Re:Of course...
sigzero on 2008-12-02T13:18:36
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.
Re:Of course...
markjugg on 2008-12-02T13:33:08
... 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 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 competitor Mojo (from Catalyst own original author) runs decently in CGI with many of the same features. Clearly taking a long time to load is not a prerequisite for being "modern".
Re:Of course...
jrockway on 2008-12-03T09:28:37
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.
Re:Of course...
markjugg on 2008-12-08T16:12:52
If someone wants to start with a lighter-weight framework and use it combination with Moose, they are quite welcome to. DayDayUp 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.
Re:What’s the point?
markjugg on 2008-12-04T18:21:47
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 Type has "$ENV{MOD_PERL}" conditional logic throughout the code base... it's rather messy. Switching to HTTP::Engine (or similar) would be a big improvement for that kind of project.
I would agree that if you only ever plan to deploy in CGI, than an extra backend abstraction layer is just extra waste and complexity.
