Re: [gtk-list] Re: how can I trust glib when it has so manymemleaks?

[Paul Barton-Davis <pbd op net>]

>Regarding this memory allocation problem, and the claim that leaving it to
>malloc would be slow: has anyone actually profilled it, and are there any
>numbers to support the claim?
>   [ ... ]
>
>My guess is that any program that also does anything useful spends
>insignificant time on memory allocation. 

This is normally true, but what is also true is that when a useful
program does do memory allocation, it often wants low latency from the
allocator. Keeping a pool of chunks of the same size does a great deal
to reduce latency in situations where you constantly allocate (and
sometimes or always release) blocks of the same size. 

Your numbers, for example, suggest an average time of 9 usecs to
allocate a chunk of memory. If I'm writing a DSP application (which I
am:) and I need to allocate memory in the middle of the DSP loop
(which admittedly, I generally try to avoid like the plague), and I
have 50usecs to go to meet my scheduling deadling), anything I can do
to reduce this time is a big help.

--p