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
From:
Jan Dubois
Date:
August 16, 2010 15:47
Subject:
RE: Patch to make string-append on win32 100 times faster
Message ID:
016201cb3d95$080e7de0$182b79a0$@activestate.com
On Mon, 16 Aug 2010, Wolfram Humann wrote:
> (All on an unpatched perl 5.10.1 with usemymalloc=n and usemymalloc=y.
> Starting with an empty my @ar2;. Code given is an additional line in my
> array of tests, but could also run stand-alone)
> 
> 1) 'append $i' => sub{ for my $i (1..1E3){ $ar2[$i] .= $c1E2 for 1..1E3 } }
> That's the 'good' case: Append 1000 times to one string, move to the
> next string, append 1000 times to that one, move to the next...
> GNU malloc:    238.8 ms
> Perl malloc: 164.8 ms
> 
> 2) 'append $_' => sub{ for my $i (1..1E3){ $ar2[$_] .= $c1E2 for 1..1E3 } }
> That's the 'bad' case: append to each string once, than again to each
> string,...
> GNU malloc:  57143.0 ms
> Perl malloc: 298.0 ms
> 
> Jan, if possible, could you run that on your before-and-after-the-patch
> compiles?

Before, GNU alloc:
	append $i:   220.4 ms
	append $_: 12879.6 ms

Before, Perl alloc:
	append $i:  200.4 ms
	append $_:  297.6 ms

After, GNU alloc:
	append $i:  190.9 ms
	append $_:  282.8 ms

After, Perl alloc:
	append $i:  198.2 ms
	append $_:  269.7 ms

So I guess as expected: GNU malloc improve a lot, Perl malloc is unaffected.

I haven't looked at total memory consumption for these tests, so I can't
confirm that the memory usage for Perl malloc() is unchanged.  I strongly
suspect that to be the case though.

Cheers,
-Jan



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About