I don't see that on FreeBSD.
Win32's malloc() is particularly stupid that way. You trigger this problem in spades by allocating a bunch of identically-sized buffers that are larger than the typical allocation size and repeatedly freeing them then waiting then reallocating them.
Win32's malloc() gets this case so amazingly wrong that it isn't even funny anymore. When you free the buffers, it leaves a bunch of fixed-size holes in the heap. Then, as tiny things get allocated, it takes a tiny chunk out of each hole (so broken it doesn't even take a bunch of tiny chunks out of the first hole before moving on to the second).
Build a Perl that uses Perl's malloc and you'll likely not see this problem either.
- tye
In reply to Re^3: Benchmark.pm: Does subroutine testing order bias results? (Win32 malloc)
by tye
in thread Benchmark.pm: Does subroutine testing order bias results?
by jkeenan1
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |