[ disclaimer: I am being funded to do this work ]
I've been looking into bottlenecks in a tight fetch loop with millions of
rows, e.g.
$sth->bind_columns(...);
while ($sth->fetch) {
# do a small amount of work
}
In the particular case I've been investigating, the method lookup in
XS_DBI_dispatch() contributed a measurable part of the total loop time;
in particular, when as a test I added very crude and hacky caching for the
lookup of the inner fetch method, the execution time for the loop dropped
from 23.0s to 19.2s.
So, I would like to attempt to add a method cache to XS_DBI_dispatch()
(and possibly see if anything else can be tweaked).
My questions are:
* Would such a patch be welcome in principle?
* Any gotchas that I might not be aware of (I'm not familiar with DBI/DBD
internals apart from what I've played with for the last few days).
* What's the earliest perl we have to maintain compatibility with?
* Does the test suite already have good coverage for method lookup
(especially where methods are redefined or stashes modified, i.e. the
sort of thing that would invalidate caches), or should I add some?
* can I rely on _install_method() being the only way that XS CVs can get
to point to XS_DBI_dispatch()?
* To what extent (if any) is DBI allowed to cheat when it comes to
bypassing the perl API (in particular I'm thinking of the method
invalidation stuff which I don't think has always been part of the API).
Thanks,
Dave
--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
-- Bill Royston