[Dbix-class] (no subject)

[fREW Schmidt]

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.austin at 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 <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
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20120703/a8d=
ddccb/attachment.htm