[Catalyst] Re: Catalyst vs Rails vs Django Cook off

[Sébastien Wagener]

What about profiling real world applications where the Catalyst seems to
be the bottleneck? 

On my production server, database requests are usually quite fast, so
most of the time is spent in perl code, and here are the first lines of
a "dprofpp -r" on my local 2.8 Ghz Laptop (production database,
Algorithm::C3 0.06, mod_perl deployment, as I do not want to use FastCGI
and dprofpp -F), for a repeated lost-password/login/change
password/logout cycle (totally about 1000 requests):

Total Elapsed Time = 142.8513 Seconds
         Real Time = 142.8513 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 13.7   19.56 19.569  53920   0.0004 0.0004  NEXT::ELSEWHERE::ancestors
 11.0   15.83 77.300  57155   0.0003 0.0014  NEXT::AUTOLOAD
 2.61   3.731  3.731 485987   0.0000 0.0000
Class::Accessor::Fast::__ANON__

It appears that 39.121 (exclusive) seconds out of 142.8513 seconds, i.e.
about 27.4% of the running time of my application are spent in
subroutines which would probably not even exist in a compiled language
like C++, or which could at least be ignored in such a language...
(correct me if I am wrong)

I do not want to criticise my personal profiling here, I am going to do
that if I have more time. My point is: Do not talk about benchmarks but
try to make real world applications faster. There are real world
instances where Catalyst, DBIx::Class and related modules contribute a
significant part to the running time of the application. If it is
possible to reduce this part by a reasonable amount of work, try to
reduce it. I do not mind a framework that speeds up the development
time, but results in slightly slower requests if I know that the
Catalyst team does not ignore the speed of its framework. I am not
claiming that the team ignores performance, there have actually been
made impressive improvements in Algorithm::C3 and so on. 
Just go on, and do not waste your time to build benchmarks to impress
marketing people ;-)

Sébastien

On Wed, 2007-01-17 at 12:30 -0500, Perrin Harkins wrote:
> On Wed, 2007-01-17 at 15:12 +0100, Robert 'phaylon' Sedlacek wrote:
> > When I request a resource from a Catalyst application, two things are
> > executed: The framework logic, and my application logic. But this is not a
> > "first the one, then the other" execution. During the request, the
> > framework calls my application logic to get some response together, and my
> > application logic uses the framework logic in a convenient way. The
> > dispatching (read: The decisio on what part of my application logic to
> > execute) is a rather small part.
> 
> That was my point actually: the dispatching (plus the abstraction layer
> for accessing things like the query string from the web environment) is
> nearly all of it, in terms of performance.  A couple of calls to
> $c->forward() and $c->stash() are negligible, and all the rest is either
> your code or some non-Catalyst CPAN module.
> 
> Regarding the DBI analogy, the thinking is pretty simple:
> 
> - DBI is big, much bigger than Catalyst.
> - DBI has tons of functionality in it, like a profiler, database schema
> introspection, and a proxy system.
> - If someone made a benchmark comparing DBI to JDBC based on query
> speed, no one would complain that they didn't test the speed of the
> other features, even though you might use them.  Query speed is the most
> relevant thing to benchmark for DBI, just like mapping URLs to methods
> is the most relevant thing to benchmark for Catalyst.
> 
> The benchmark still sucks though, even as a dispatcher test.  He gave it
> the easiest possible URL.
> 
> - Perrin
> 
> 
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/