On Fri, Mar 02, 2012 at 03:11:17PM +0000, Tim Bunce wrote: > > > > The second patch, which makes DBIS more efficient, is a lot more complex, > > and more likely to break things (especially as it's changing a bunch of > > macros that are directly #included by the DBD drivers. You may need to > > bump API version numbers; I don't understand that bit. > > I'm concerned that changing the API, and thus forcing all compiled > drivers to be recompiled at the same time the DBI is installed, > isn't worth the gain. Especially as drivers shouldn't be using DBIS in > any hot code anyway.
I finally got around to looking at DBD::Pg and was horrified to discover the number of DBIS calls made by hot paths in the code. Most are hidden behind various tracing macros. Even fetch calls 3 + 3 * num_of_fields! Then I looked at DBD::Oracle and discovered the same kind of thing. Which is particularly disappointing for me as I wrote the tracing mechanism it uses (though maybe that pre-dated thread support). Anyway, the upshot is that getting DBIS calls out of major drivers will require a fair bit of work. It's just grunt-work really, nothing complicated. As you noted with DBD::mysql, Dave, the performance gains are worth it. Any volunteers? Naturally I'll be happy to suggest an approach I think will work well (basically an extension of that used by DBD::Oracle). Dave, I'll get back to you about the DBIS changes soon, I hope. Tim.
