On Tue, Nov 12, 2013 at 9:16 AM, Patrick Meidl <pme...@ist.ac.at> wrote:
> On Mon, Nov 11 2013, Rob Kinyon <rob.kin...@gmail.com> wrote: > > > In terms of speed benchmarks, those are mostly useless. 99% of the > > time spent within an ORM is actually time spent within the database. > > 90% of that speed is dependent on how badly you designed your tables. > > I would like to object. if you properly designed your tables, and in > particular if you do proper normalization, the object instantiation is > a major overhead, which we could only overcome by using HashrefInflator > in some of our use cases. > Agreed. DBIx::Class has a pretty significant overhead for inflating result objects. Most of the time this doesn't really matter but occasionally it does. For big result sets, sometimes the majority of time ends up being spent, not waiting the database server or doing I/O but in user space doing "Perl gymnastics". Occasionally, we too, find ourselves falling back to raw DBI. This is probably true of any ORM though - at least to some degree. Convenience comes at a cost... Also, as mentioned earlier, the power of the result set concept in DBIx::Class shouldn't be underestimated. It's an extremely powerful feature. /L
_______________________________________________ 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
