On Fri, 10 Feb 2012, Paul Wallingford wrote: > So you are suggesting either ditching Mason for some other framework > (interesting suggestion on the Mason list) or adding more stuff to the > mix of an already slow system. FWIW, I do not think it is Mason itself > that is slow, but Moose certainly is.
Yes, basically. Or as Jon pointed out, you can use bare Plack to handle the "turn my app into a daemon" thing. > I have two apps - same server. One is an old shopping cart system I > wrote long ago with Perl and no additional modules. The Perl CGI > program is 335KB long and caches in memory after the first invocation. > Each invocation requires a new Perl interpreter start up - there is no > FastCGI or mod_perl involved. It will sustain over 20 page views per > second. > > Same server - A one page Mason 2 app that is essentially nothing. It > sends a very small amount of html to the browser with a couple of lines > of javascript in it. The Javascript makes a single Ajax call to the > server. I was using this to test how Mason 2 handles Ajax, since I have > written Ajax based sites in Mason 1 and know how it performs. This is > also standard CGI and requires a new Perl interpreter each time. The > pages will cache in memory after the first invocation. I don't think it's reasonable to say "I want the new shiny to run in the same environment I used ten years ago". Web development practices have changed a lot in the past 10 years ago. Although 10 years ago I still deployed everything with a persistent Perl interpreter (mod_perl 1). Nowadays I generally aim for PSGI using Starman, or mod_perl 2 as a fallback. > And you have just made my point about documentation. The FAQ is right > there on CPAN. All you have to do is a simple search. But obviously, > having a few pages of documentation on CPAN is no substitute for a book, > wiki, etc. > > http://search.cpan.org/~doy/Moose-2.0402/lib/Moose/Manual/FAQ.pod#I_heard_Moose_is_slow,_is_this_true? Especially funny since I wrote a huge chunk of the Moose docs. As far as a book, the reason we don't have a Moose book is that it takes a lot of time for very little money. I'd guess that all told, I made maybe $10-15/hour working on the original Mason book. Obviously, it also helped my career indirectly in a lot of ways. But I don't really need that sort of career boost these days. I have offered a full day Moose course at some conferences in the past, and I could probably fly somewhere to offer it if there were enough interested parties. It's gotten quite good reviews from my students. > 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. Yes, I've personally done a _lot_ of profiling on Moose. If you looked at the Moose Changes file you'll see a lot of changes mentioning optimizations and speedups that I personally implemented. Unfortunately, the biggest changes were to runtime performance. It's really hard to improve Moose's compile time performance without making runtime much slower. Basically, the reason Moose is slow at compile time is that it does a _lot_ of one-time-only optimization tricks for your code (if you ask Moose to make it immutable, which you should). This involves a lot of code generation and eval of that code. At this point, I only see a few possibilities for speeding up compile time: 1. Generate the eval'able code at installation time and dump it into .pmc files. This means we wouldn't even need to invoke Moose at compile time for pre-compiled module. This is actually getting closer to possible. 2. Greatly speed up the internals involved in compile time. I'm not sure how possible this is. At this point, we seem to be up against fundamental slowness in the Perl interpreter for the operations we're doing. 3. Change the Perl interpreter to speed up our compile time operations. This is part of what the Perl 5 core MOP work I mentioned is about, but the arrival time for this is _at least_ 15 months out, if not more. #1 is the most likely possibility in the near time, but it's really quite difficult. Patches are certainly welcome, but it's a daunting task, even for the core Moose devs. >> However, if you're really, really stuck using CGI, Moose is not a good >> choice. I'm not sure how good Mouse is either. It still has a bit of >> overhead. Perl may not even be that good a choice. Starting a new Perl >> interpreter for each request is a huge amount of overhead. > > As noted above, I can run a fairly large Perl CGI program that starts a > new Perl interpreter each page view fairly quickly. Sure, I can turn > that 20+ views per second into 200+ with mod_perl, but that program was > written over 10 years ago - closer to 15 now that I think about it - > before such things as mod_perl existed, and CGI was the only choice, so > it is a decent benchmark to show "progress" in state of the art. I used mod_perl extensively in the late 90s and early 2000s. It's first release was back in 1996, before I was even a professional programmer! > 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. Like Jon said, Mouse omits a lot of stuff, primarily a full meta-model, which in turn makes writing a lot of extensions much harder. > speaks for itself. (I do realize that Mason was written almost if not > completely by Jonathan and Dave has contributed to Moose and is one of > its proponents.) Mason 2 is all Jon. I'm a little insulted if you think I didn't contribute much to Mason 1. I actually wrote a large amount of what forms the current Mason 1 code and docs. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/ ------------------------------------------------------------------------------ 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 Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
