On 13/03/12 21:44, Tim Bunce 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.
On the other hand, I want whatever speed I can get so I am happy to recompile
any DBDs to get it. Do people like me have to do without improvements for the
sake of those who don't want to recompile their DBDs or can it be done in some
other way or opt in.
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).
I am happy to change DBD::Oracle or may be Yanick will.
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.
I don't think DBD::ODBC uses any DBIS stuff but to be sure I'd echo Merijn's
reply; if you could point out what to look for and an approach I'd happily
change any DBD I could run and provide patches for it (currently I have ODBC,
Pg, Oracle, CSV, SQLite, mysql and all those you get with DBI).
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
