Re: memory allocations.

[Ulrich Drepper <drepper redhat com>]

Alan Cox <alan redhat com> writes:

> You can have one pool per thread group and hash - which for low
> counts cuts the number close to zero. Thread specific pools are a huge
> win in many studies I've seen

This is already done.

The costs which are visible are unavoidable with the memory allocation
in a multi-threaded application.

> Lots of the glib ones are small but variable size. For fixed size objects
> you can use a slab allocator with per cpu front caches. I've not seen
> much to beat it - so I agree in principle about big objects.

Objects of all sizes can be handled this way.  You don't have to
allocate blocks with the exact size.  Allocate in chunk of, say, 32
bytes.

> Its more a question of - should we clean up lots of yards, or can we
> invent a better type of yard that self cleans.

There is not much more you can do to the malloc.  I haven't written
the malloc code so you cannot blame my constantly cited inability.
Doug Lea has a lot of experiences and the extra modifications on top
of this are done by somebody who mainly dealt with these issues.

And to answer your question: it definitely is necessary to clean all
the code up.  First, even with some hack to get GNOME-specific use of
malloc faster this still would mean a large speed gain.  Any malloc
call is expensive (well, actually free is more expensive).

Secondly, give new code the correct guiding by showing in existing
code how it has to be done.

If this isn't possible go with GC.  gcc did this because memory
handling was too complex (and obstacks too dangerous).

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------