[Van-pm] January van.pm meeting

[Alex Pavlovic]

Hi,

On Friday 27 January 2006 13:57, Jesse Sherlock wrote:
> For rapid application development catalyst wins hands down, it does
> however bring alot of behind the scenes magic to the table, that means
> it's much more complex (CGI::Application without any plugins is very
> very simple) and slower as well.

Hm, while true what Jesse had to say earlier I have to disagree a little bit 
on this subject. Catalyst core does make heavy use of code 'evals' to get 
everything to work, while bad for your perl debugger, I am not sure how heavy 
of an impact is this when run under mod_perl or FastCGI, I never measured C:A 
and Catalyst. Performance wise, applications written with Catalyst in my 
opinion can scale, especially true with lighttpd where load balancing is part 
of the server.

One of the bigger bottlenecks is probably ORM layer IMHO, such as DBIx::Class 
for the model. Here you gain faster and more rapid development time while 
sacrificing performance. It has to know how to translate your objects into 
native sql relations and vice versa. This is one of the reasons I avoid ORM's 
right now and go with pure DBI and also the fact that you can write more 
expressive queries easier if you are familiar with SQL. Some of my queries 
involve things like for example ( plpgsql procedure calls, correlated value 
subselects, self joins, etc... ) I would imagine for some of them you would 
have a hard time trying to accurately describe this in ORM, while it could 
certainly be possible though. 

Just remember that you can always drop the ORM and go with pure DBI. I 
personally use Catalyst::Model::DBI::SQL::Library, that I wrote, which allows 
for nice separation of concerns ( sql queries get pushed into separate "ini" 
like files, away from your perl code ) while you can still work with them 
from within Catalyst either in controller or model using traditional DBI 
interface. Another thing this allows me is then at some later time I can 
actually revisit my queries, analyze and optimize them to peform better 
( controlling planner with explicit join clause for example ).  Some would 
call this approach minimalistic, I call it time tested and fast. 

>
> They really are different solutions for different problems, if you
> need a fast, lightweight framework because you have huge amounts of
> traffic then cgi::application or no framework at all are your best
> choice. If this isn't the case then it's Catalyst all the way.

Yes or use a stripped down version of Catalyst, as illustrated above. This is 
what's great about Catalyst, as I said in the earlier post, it doesn't lock 
you into anything, you still have the complete freedom to choose what 
plugins, models, etc... you wish to use. 

I might do some actual benchmarking one of these days, I will post the results 
as soon as they are available for people to view.


Thanks.