Re: Reducing memory footprint?
Alan Burlison (Alan.Burlison@uk.sun.com)
Thu, 11 Mar 1999 12:10:34 +0000
Nick Ing-Simmons wrote:
> >> I agree Solaris malloc is slower, I don't remember _that_ much difference
>
> My guess was that "Solaris malloc" may be a different beast when found
> via thread library - we are not the only ones that pay a thread-safe
> overhead. e.g. if libc malloc does no locking, but -lpthread malloc
> does lots of locking it could be a lot slower.
No - there is only one version of malloc - the one in libc, which is
thread-safe.
I've done a very simplistic test - a script that allocates 2,560,000
10-character strings and pushes them onto an array. The results are as
follows:
malloc version
System Perl Difference
Heap space 140184k 108824k 22%
Elapsed time 1:30.274 1:23.708 7.3%
User time 1:27.881 1:22.653 5.9%
System time 0.976 2.076 53%
The size difference I can believe - after all perl's malloc is
(hopefully!) pretty optimal for perl usage. I can also believe the 5.9%
difference in user time - the Solaris malloc has the overhead associated
with being thread safe - I think less than 6% overhead for thread safety
is pretty impressive. The system time is also explainable if you count
the number of calls to brk (truss -c). Perl malloc makes 202 calls to
brk during the script execution, but Solaris malloc makes 26,880 calls!
It seems pretty conclusve that on non-threaded perl the perl malloc is
to be preferred over the Solaris one. However, I think it is unlikey
that this will be true for threaded perl. A *lot* of effort has gone
into making Solaris malloc thread-hot, i.e. scalable. In 2.6 there
isn't a single malloc mutex, there are lots of them. On large SMP
configs running malloc-intensive apps malloc can quite often be the
limiting factor in scalability - I personally I have seen *negative*
scalability on a C++ app that was making very heavy use of malloc.
Alan Burlison