Tim Bunce <[EMAIL PROTECTED]> writes: > On Tue, Jan 24, 2006 at 02:23:04AM -0800, Gisle Aas wrote: > > I suggest this patch (relative to 1.50) to get PERL_NO_GET_CONTEXT > > going. Any reason not to? > > It's been a while since I looked into the issues so I'm not sure off-hand. > > The two big issues are 1) wanting to avoid having to recompile drivers, > and 2) remaining backwards compatible with perl 5.6.x. > > Has this patch been tested in both those directions?
I tried it with both ActivePerl 5.6 and 5.8 and with the DBD::mysql built by our PPM server. They all seem happy. This patch does not modify any of the function signatures so it should not really be any compatibilty issues. It is only when you start adding aTHX_ and pTHX_ to the functions this happen. All that happens with this patch is that we do a single call to retrive my_perl at the beginning of the functions of DBI.xs instead of doing it over and over each time any of the Perl API functions are called. BTW, when you run 'make test' it will in the end tell you the "Testing handle creation speed...". This patch did increase this speed by 13-15% for ActivePerl; before: 16666 NullP sth/s perl 5.006001 i686-linux-thread-multi (gcc 2.95.2 -O2) after: 19230 NullP sth/s perl 5.006001 i686-linux-thread-multi (gcc 2.95.2 -O2) before: 15384 NullP sth/s perl 5.008007 i686-linux-thread-multi (gcc 2.95.2 -O2) after: 17241 NullP sth/s perl 5.008007 i686-linux-thread-multi (gcc 2.95.2 -O2) I have not tried to meassure any performance gains otherwise. > I think it's time to move on from 5.6 now so I'm think that the next > DBI release will be the last that officially supports 5.6. > I'll send a note to dbi-users and see what the reaction is :) ActiveState certainly want to continue to support DBI for perl-5.6, so we'll have figure out something if you drop support for it. I don't think the PERL_NO_GET_CONTEXT mechanism is any different between 5.6 and 5.8 so does not have to be the trigger for this transition. Dealing with Unicode issues is certainly easier if you don't have to care about 5.6. Personally I would like to see perl-5.6 still supported as it is a faster perl in general and if you don't need the Unicode stuff it seems fine to just stay there. > Having done that I'm happy to be a little more radical for a while. > (So I'm probably saying that I'll add this patch to 1.52 not 1.51.) That's good enough for me, but I also think this patch should be safe right away. I can't think of anything that might break. > > Further, is it really problematic to start passing 'my_perl' as > > argument to these functions? Are they ever called from drivers? > > Quite a few (see struct dbistate_st in DBIXS.h): > > char * (*neat_svpv) _((SV *sv, STRLEN maxlen)); > imp_xxh_t * (*getcom) _((SV *h)); /* see DBIh_COM macro */ > void (*clearcom) _((imp_xxh_t *imp_xxh)); > SV * (*event) _((SV *h, const char *name, SV*, SV*)); > int (*set_attr_k) _((SV *h, SV *keysv, int dbikey, SV > *valuesv)); > SV * (*get_attr_k) _((SV *h, SV *keysv, int dbikey)); > AV * (*get_fbav) _((imp_sth_t *imp_sth)); > SV * (*make_fdsv) _((SV *sth, const char *imp_class, STRLEN > imp_size, const char *col_name)); > int (*bind_as_num) _((int sql_type, int p, int s, int *t, void > *v)); > int (*hash) _((const char *string, long i)); > SV * (*preparse) _((SV *sth, char *statement, IV ps_return, IV > ps_accept, void *foo)); > int (*logmsg) _((imp_xxh_t *imp_xxh, const char *fmt, ...)); > int (*set_err_sv) _((SV *h, imp_xxh_t *imp_xxh, SV *err, SV > *errstr, SV *state, SV *method)); > int (*set_err_char) _((SV *h, imp_xxh_t *imp_xxh, const char > *err, IV err_i, const char *errstr, const char *state, const char *method)); > int (*bind_col) _((SV *sth, SV *col, SV *ref, SV *attribs)); > > > > The RoadMap file seems to indicate that there would be code changes needed > > for the drivers to support PERL_NO_GET_CONTEXT. > > If a my_perl param was simply added to those functions then drivers > would break until their code was changed to add the extra argument. > > In some cases the calls are made from macros provided by the DBI so > a simple rebuild of the same driver source would fix those. I don't > know off-hand how many that applies to. It might be all of them, > if we're lucky. > > I'd like to avoid forcing drivers to be changed, or even recompiled. > Installing a new DBI shouldn't ever break old code. Also, for the > driver authors, it should be easy for a driver to build against old and > new DBI APIs. Those requirements make it tricky. Still doable, just > more thought/work. > > For example, an extra set of entry points could be added that have the > my_perl param and the DBI macros changed to use them. That way old code > uses the old entry points and the new faster entry points can be used > by simply rebuilding the driver. (Assuming all are called via > DBI-supplied macros.) Sounds like a plan. I'll see if we can find time to do anything about it. --Gisle
