Re: DBD::Pg, DBD::Oracle and others are slow with threads due to DBIS
"Martin J. Evans" <[email protected]>
| Newsgroups | gmane.comp.lang.perl.modules.dbi.sybase.devel |
|---|---|
| Organization | Easysoft Limited |
| Message-ID | <[email protected]> |
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