[EMAIL PROTECTED] wrote:
In victori's remarks, he calls for a change in Catalyst and points to
the other advantages to to this framework, mostly related to ease of
coding. While the whole reason I came to Catalyst is because I'm
comfortable with Perl and don't want to learn Ruby, I'm worried that my
Catalyst application won't perform as well when/if my app usage becomes
very significant. Should I be concerned?
No. Six apart certainly aren't, given http://vox.com/ is a Catalyst app.
Again, I'm not interesting in hearing about how Rails/Ruby/Django/Python
sucks, but in facts about real performance of Catalyst.
The reality is that victori's benchmark successfully measures only the base
overhead of a request in an app with very few URL endpoints; Catalyst's
dispatch mechanism is optimised for speed of dispatch for large applications
and for allowing complex dispatch logic elegantly.
Besides which, I've never yet seen a production application (and between
Shadowcat's client portfolio I've seen not a small number thereof) where the
dispatch overhead was even statistically significant to the overall
performance - the bottleneck has always been either data retrieval or template
rendering.
--
Matt S Trout Offering custom development, consultancy and support
Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information
+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
