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?) ________________________________ From: Clinton Pierce [mailto:clintp@gmail.com] Sent: 29 January 2008 16:25 To: Steve Hay; perlbug-followup@perl.org Subject: Re: [perl #50352] Perl 5.10 Storable extremely slow for large trees of data As a followup to myself, I ran perl -V on the 5.6 build that's nice and fast. The usemymalloc=n would seem to indicate that it's already using the system-supplied malloc. Summary of my perl5 (revision 5 version 6 subversion 0) configuration: On Jan 29, 2008 11:19 AM, Clinton Pierce <clintp@gmail.com> wrote: More detail: There is definitely a difference between 5.6.2 and 5.10.0, but a far more significant difference is brought about by using different mallocs: With 5.10.0 the freeze takes about 2.7 secs with the system malloc and 0.03 secs with perl's malloc. With 5.6.2 it takes about 0.9 secs with the system malloc and 0.03 secs with perl's malloc. Not sure why the system malloc figure is slower with 5.10.0, but if the 0.03 secs is more like the time that you were seeing previously, could it be that your 5.6.x build was using perl's malloc and now your 5.10.0 build is using the system malloc? (ActivePerl builds use the system malloc because perl's malloc currently doesn't work with "-D PERL_IMPLICIT_SYS", which is required for the fork() emulation.) Good find. And that pretty much leaves me up a creek. I can't really use a self-built Perl for Production in my situation, and the supplied one is far, far too slow. Maybe I'll have to find another distribution source or stay on 5.6.Thread Previous