develooper Front page | perl.perl5.porters | Postings from August 2010

Re: Patch to make string-append on win32 100 times faster

Thread Previous | Thread Next
Ben Morrow
August 16, 2010 10:19
Re: Patch to make string-append on win32 100 times faster
Message ID:
Quoth (Reini Urban):
> 2010/8/16 Jan Dubois <>:
> >
> > Could you provide some evidence for this claim? �The only way a
> > "better malloc" can prevent this slowdown is by doing some kind
> > of overallocation itself. �Since the algorithm in this patch
> > is not necessarily cumulative with the overallocation by malloc()
> > it is very well possible that the change has no effect at all
> > on systems with a overallocating malloc().
> This is just theory. I KNOW that plain gnumalloc and freebsd realloc
> do work fine.
> But now that we have the mess someone can test it. I don't have such systems
> so I cannot test it.

The test I referred to running under FreeBSD is at
, and the benchmark in question is at
. The difference between -Dusemymalloc and not is *huge*, for instance

    5.8.8, system malloc
        1E7 chars + 1E4 x 1E2 chars: 7159.0 ms 
    5.8.8, mymalloc
        1E7 chars + 1E4 x 1E2 chars:   45.3 ms 

Now, it's possible that benchmark is faulty, or that perl's allocation
strategy has changed significantly since 5.8.8, but you would need to
give some reason for believing that before blindly asserting that
FreeBSD's malloc is the fastest thing in the world and nothing could
possibly improve its performance.

> Uuh, nobody ever complained about freebsd realloc performance.
> It was always the fastest on the planet and still is.

Not for perl's usage patterns, apparently. This is borne out by the fact
that ports perl has been built with -Dusemymalloc forever.

> > Note thought that I added this remark for discussion about disabling it
> > under -Dusemyalloc:
> >
> > | b) Should the new over-allocation also be used under -Dusemyalloc. �It
> > | � �will provide less benefit there, but also come at a lower cost because
> > | � �the newlen can still fall inside the already allocated bucket size
> > | � �anyways. �I don't have any strong opinion if it should be disabled
> > | � �in this situation or not.
> >
> > But as I stated above, I don't think it will make much of a difference either
> > way for the -Dusemyalloc case, but would love to see some comprehensive
> > benchmarks.
> At
> were a lot of benchmarks and profiling data.
> He is testing string sizes of 1e5-1e7 byte not just pagesizes, piping
> a typical pdf to perl.

Are you saying this is a bad benchmark, for some reason? If you can
supply a better I'd be happy to run it for you.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About