I agree, I am curious what driver was used etc. I have seen MUCH better numbers than this, but I'm on a relatively esoteric platform. On Jul 2, 2012 10:59 AM, "Devin Austin" <devin.aus...@gmail.com> wrote:
> 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 <es...@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 > > _______________________________________________ > 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 >
_______________________________________________ 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
