On Fri, Oct 06, 2006 at 04:32:45PM -0700, Jerry Hedden wrote: > Jerry D. Hedden wrote: > > It's not the use of overload.pm that is still the issue. > > It's just that generating the Class=TYPE(0xADDR) string > > takes so much time. Your patch puts stringification of > > overloaded and non-overloaded objects nearly on a par. > > However, both still pale in comparison to getting a TID: > > Nicholas Clark wrote: > > Well, if stringification of references really needs to be as fast as > > possible > > > > [code delete] > > > > which gets me > > > > Rate tid thr obj > > tid 472/s -- -13% -17% > > thr 539/s 14% -- -5% > > obj 565/s 20% 5% -- > > > > but I'm not sure if it's really worth making this change to > > sv_2pv_flags. > > For less than a couple dozen lines of code, this is a great > improvement. I would recommend it. I get the feeling that > people do this sort of thing more often than you might think.
Well, I was basing the assumption on the coverage data for the Perl regression tests. I'm aware that the basic tests do little with references or objects, but only 38335 times through the code (and of those 36577 were unblessed references) compared with tens of millions for some of the real hot spots made me think that it wasn't actually that common: http://www.maddingue.net/perlcover/cover1/cover_db/--sv-c.html > > [Hmm, thinking about it further as I'm doing all the > > length calculations explicitly I don't actually need a > > mortal SV for a scratch buffer. I could just malloc() it > > directly, and use SAVEFREEPV() to free it later] > > And make it even faster? Sounds good. Please do it. Gets to this (comparable with old numbers): Rate tid thr obj tid 462/s -- -27% -31% thr 636/s 38% -- -6% obj 674/s 46% 6% -- (and curiously synced up with your tid change) this: Rate tid thr obj tid 459/s -- -30% -32% thr 657/s 43% -- -2% obj 674/s 47% 3% -- Which I committed as change 28961. If one is wanting something unique from a reference for a hash key, pack "J", $ref; generates a much shorter string, and (prior to this change) should be much faster. Nicholas Clark
