httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: Malloc v.s. pools (was Shared memory in APR.)
Date Fri, 16 Jul 1999 15:22:11 GMT

In article <> you wrote:
> Ralf S. Engelschall wrote:
>> So when it comes to the whole topic of "whether one needs a pool facility in a
>> server" we all agree, of course. But when it comes only to the topic "whether
>> a malloc() wrapper library is needed for performance", I'm still not convinced
>> that the statement "malloc() is slow and has to be increased for performance
>> reasons by using a wrapper which allocates in larger chunks" is true. 
> The key is that for many apps that use malloc() extensively, the implementation
> of malloc on that platform is a black-box. One has no idea of the
> actual speed of the malloc available and how often it calls sbrk()
> for example. There are some dog-slow versions of malloc out there,
> and historically the versions found in libc have been the slowest
> (hence the existance of lmalloc on various platforms, usually
> provided for X).
> It's for that reason that pretty much any app that uses malloc a
> lot (gcc, INN, Perl, etc...) provides their own, private, faster version.
> Better the devil you know than the devil you don't.

Ok, sure. So when I look at this from that point of few, it's as following:
The argument of a slow malloc() is often true when we talk about the vendor
version. But as long as an app does ship with its own fast version using
directly malloc() (from this lib!) this has NOT to mean that performance has
to be reduced. Fine, that's what I intuitively expected. With a reasonable own
malloc() it should be no problem as long as one do not need/want the nice
semantics of a pool system, as Ben H. mentioned.

                                       Ralf S. Engelschall

View raw message