Clinton Pierce wrote: > On Jan 29, 2008 1:07 PM, Steve Hay <SteveHay@planit.com> wrote: > >> Yes, the usemymalloc=n means your 5.6 was using the system malloc >> anyway, so that doesn't explain your problem (although the perl >> malloc would still solve it if you were able to use it). >> >> I noticed that you were using 5.6.0 rather than the 5.6.2 that I >> tried, so I thought I'd give 5.6.0 a try too. I found that Storable >> 2.18 doesn't build with it, and I had to go back to 2.12 to get one >> that works. >> 5.6.0+2.12 (with the system malloc) takes about 0.7 secs here, which >> is a shade faster than 5.6.2+2.18, but not by much. >> >> The part of 2.13 onwards that doesn't build with 5.6.0 is UTF8 stuff >> (bytes_from_utf8 caused a linker error), and I see 2.13's ChangeLog >> mentions handling utf8 data. Perhaps this is the difference? (i.e. >> Your >> 5.6.0 used an old Storable that doesn't do UTF8 properly, and 5.10.0 >> is slower because it uses the current Storable which does handle it?) >> > > That is a possibility. We're not using any UTF8 stuff here at all -- > it's all 8-bit ASCII -- so I wouldn't have noticed a difference at > all over the years. > > I checked the Storable in the 5.6 distribution we're using here -- > Version > 1.010. Maybe I can get that version to compile against Perl 5.10? I > honestly don't know. Not straight out-of-the-box. I tried with 1.0.14 and then again with 2.12 (the version prior to the UTF8 changes), but they both choke on "case SVt_PVBM" in sv_type(). I don't know how to workaround that to get it building with 5.10, but if it (and any other build problems) can be worked around then I guess there is no other reason why these older versions shouldn't work with 5.10, and it would be interesting to see if that gives you your speed back.Thread Previous | Thread Next