[Dbix-class] (no subject)

[Marc Espie]

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.