[Dbix-class] (no subject)

[Devin Austin]

It would be kind of nice to see the code these benchmarks were run on to get and idea of where the bottlenecks actually are.

Sent from my iPhone

On Jul 2, 2012, at 8:21 AM, Marc Espie <espie at nerim.net> wrote:

> On Mon, Jul 02, 2012 at 07:33:38AM +0000, Dami Laurent (PJ) wrote:
>> Hi DBIC list,
>> 
>> For info, I gave a talk at the French Perl Workshop 2012
>> about comparing DBIx::Class (DBIC) and DBIx::DataModel (DBIDM);
>> at this occasion I did a few benchmarks that may be worth sharing
>> with you :
>> 
>> Extract & print 2 columns from a single table (109349 rows)
>>  - raw DBI                    0.43 secs
>>  - DBIC regular              11.09 secs
>>  - DBIC hashref inflator     10.06 secs    
>>  - DBIC 'raw data' (cursor)   4.48 secs
>>  - DBIDM regular              4.00 secs
>>  - DBIDM fast statement       2.25 secs
>> 
>> Join 3 tables & print 4 columns from the join (113895 rows)
>>  - raw DBI                                     1.36 secs
>>  - DBIC regular                               46.70 secs
>>  - DBIC, join & +columns                      15.50 secs
>>  - DBIC, join & +columns, hashref inflator    14.17 secs
>>  - DBIC, join & +columns, 'raw data' (cursor)  6.59 secs
>>  - DBIC, prefetch                            146.29 secs
>>  - DBIDM regular                               5.01 secs
>>  - DBIDM fast statement                        3.28 secs
>> 
>> I was not surprised to find out that DBIC is slower
>> than DBIDM :-) ; however, I was quite surprised to 
>> find out that, among DBIC mechanisms :
>> 
>> a) 'HashRefInflator', often advocated as being the fast way to get
>>   data from DBIC, actually doesn't seem to bring any significant
>>   benefit. 
>> b) 'prefetch', also advocated for doing speed improvements, indeed 
>>   does its job of sparing queries to the database, but then has  
>>   such a high cost in handling the retrieved data that it becomes
>>   the most expensive method.
>> c) 'cursor', which goes directly to the DBI layer and therefore
>>   loses all ORM features for the retrieved data, nevertheless 
>>   adds a significant cost over raw DBI.
> 
> Not so much a surprise... a bit sad, though.
> 
> Compare Tim Bunce's presentation of DBI (which does emphasize that speed
> is really important) with the mostly "don't care about performance at all"
> in DBIx::Class.
> 
> I know that I've given up on DBIx::Class myself, precisely because there's
> such a huge overhead (most of which isn't really that explainable, actually,
> there's something as over-generality).
> 
> Question: did you consider adding more classes to your study ? I'm thinking
> of John Syracusa's Rose framework, which
> - is quite a lot cleaner than DBIx::Class
> - doesn't try to include the kitchen sink.
> 
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk