On Tue, 13 Mar 2012 21:44:06 +0000, Tim Bunce <tim.bu...@pobox.com> wrote:
> 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! When hidden, it won't stand out to the maintainers. How do we/I see where it happens? Do you have a (short) guide to check if my/a DBD (CSV, Unify, File) uses those too? > 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. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
