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
Post by Perrin HarkinsPost by Robert 'phaylon' SedlacekWhen 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.
- 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
_______________________________________________
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Dev site: http://dev.catalyst.perl.org/