Re: [Mason] www.masonhq.com back to work?

> 
> I do understand that much of this delay with Moose is startup and that 
> by pulling various tricks, like FastCGI or mod_perl, performance can be 
> improved past the first invocation.  I have not run a comparison test 
> using mod_perl or FastCGI yet.

Yes, much of the delay is startup - I'd be interested to see a comparison test 
with a persistent Perl environment. In my brief benchmarks Mason 2 was actually 
*faster* than Mason 1 in terms of component call overhead, because it is 
leveraging Moose's optimizations for constructors and method calls as opposed 
to implementing its own call stack etc.

FastCGI and mod_perl aren't "tricks", they are the most basic common sense 
implementation choices. As in, not starting a Perl interpreter and loading all 
your modules and reinitializing your world for every request. It's like saying 
"I don't feel like using a compiler and this hand-interpreted C is really 
slowing me down". :)  I don't begrudge you for using plain CGI in your 
environment if it works for you, but is it an important benchmark point for 
modern web development?

Check out http://search.cpan.org/perldoc?Starman for a really easy 
high-performance persistent engine to use with Plack/PSGI.

> However, note that Jonathan's rationale for stripping out the web code 
> and using Plack is that it allowed Mason 2 to run under a wide variety 
> of platforms and servers, not just Apache with mod_perl.
> 
> http://search.cpan.org/~jswartz/Mason-2.15/lib/Mason.pm
> 
> Under acknowledgements: "Thanks to Tatsuhiko Miyagawa and the PSGI/Plack 
> team, who freed me from ever worrying about server backends again."

True, but plain CGI was honestly not on the list of things I was worrying about 
in the first place. :) Someone else had to write the CGI handler for Mason 1.

> 
> Has anyone profiled Moose to find out what is actually taking so much 
> time?  I know this was done with PHP5 and a lot of the slowness (which 
> turned out to be in the way PHP4 created objects) was addressed.
> 

I'm fairly sure the Moose team has profiled and optimized a whole bunch. AFAICT 
they are not *unconcerned* about performance, but their top priority is 
creating the most powerful post-modern OO system they can and that has a cost.


> I have not tested Mouse yet, but I plan to, however, the Mouse 
> documentation states it is 4 times faster than Moose.  I was going to 
> contact the author to find out what Moose has that Mouse omits to see if 
> anything Mason critical is missing.  Of course, Jonathan would be a 
> better choice to ask that question since he would know better than I if 
> any missing features might cause a problem.

I tried using Mouse once (for CHI) and backed out quickly. There were too many 
compromises IMO to ensure compatibility between Mouse and Moose. Again, to beat 
this into the ground, the main (only?) thing Mouse saves is startup time and 
that's just not important to me in a web context where you can have a 
persistent Perl interpreter. Obviously it is more important for people using 
Mason in a non-web context.

Jon

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

_______________________________________________
Mason-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mason-users