Re: memory allocations.

[Sander Vesik <sv117949 ireland sun com>]

On Wed, 27 Feb 2002, Alan Cox wrote:

> > What an application with thousands of memory requests should do (and
> > not at the g_malloc level) is to keep memory pool for object of one
> > type.  These could eventually be kept in per-thread.  If applications
> > are allocation (and not freeing) thousands of little blocks this
> > should be handled by analyzing the object's lifetime and putting them
> > in one struct.
> 
> 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.
> 

Well, if the problem was lots of mallocs of vraiable sized objects, we
could use a zone allocator with tuned bucket sizes (tuned meaning "not
necessarily all powers of two") for allocations upto a certain size N. It
also gives a very obvious way to avoid/reduce lock contention. I don't
think we need to worry with per-thread allocation caching until we have
established there is a problem there.

But we definately need to have a size/frequency distribution graphs for
common applications and use patterns first before doing anything.

> 
> Alan
> 

	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





_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers