Re: memory allocations.

[Sander Vesik <sv117949 ireland sun com>]

On 27 Feb 2002, Ulrich Drepper wrote:

> Alan Cox <alan redhat com> writes:
> 

[snip]

> > 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.
> 

Even if there was something to be done to malloc in glibc2 (or glibcN) -
and I don't feel any need to say anything about glibc - it would still not
help the problem at hand which is "gnome applications do a gazillion calls
to malloc at startup". Which is also not really a problem that only
happens on systems using glibc.

> 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.
> 

A lot with this depends on how much can be done in the libraries and what
needs to be done upstream. The larger percenatge of this is hapenning in
the libaries the better off we are.

> 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   `------------------------
> 

	Sander

	I see a dark sail on the horizon
	Set under a dark cloud that hides the sun
	Bring me my Broadsword and clear understanding