Re: memory allocations.

[Havoc Pennington <hp redhat com>]

Ulrich Drepper <drepper redhat com> writes: 
> (1) there is a not so steep slope up to about 300k where about 110k
>     are allocated in about 9000 malloc calls.  This is probably all
>     from the same function and almost all allocations are small.  A
>     candidate for a memory pool
> 
> (2) A similar slope.  Another candidate.
> 

One of these slopes must be the font map. So it's a whole bunch of
short strings for font names.

We could pool them by just forcing them all to the same length, maybe,
though the length is in principle arbitrary.  Ideally we would not
have the font map. I think things look a lot different in Xft mode
instead of traditional X fonts mode, this is the traditonal-X-fonts
map.

> (3) This is the most important.  There is constant allocation and
>     deallocation of vey small memory chunk.  If this could be cached
>     30% of all operations would go away.

At some point in the graph we have a window onscreen, and there's just
a bit of activity each time it repaints or blinks the cursor or
whatever.

Some of the flat part may be before we get stuff onscreen.
 
> Every special-purpose allocator has the potential to be faster than a
> general purpose allocator which malloc has to be.  But the
> implementation cannot be too trivial.  It eventually has to cope with
> multiple threads and then things already get ugly.  Simple locking can
> lead to high contention.  Maintaining per-thread pools requirs a lot
> of administrative overhead.  All this could mean that a special
> implementation in fact is slower.

My impression is that it's quite hard to do as well as libc, because
libc has had a ton of effort spent on its allocator.

Havoc