Re: memory allocations.

[Sander Vesik <sv117949 ireland sun com>]

On 27 Feb 2002, Havoc Pennington wrote:

[big snip]

> Memory usage summary: heap total: 3568351, heap peak: 1037831, stack
> peak: 17308
>          total calls   total memory   failed calls
>  malloc|      39916        2395272              0
> realloc|       4269         598560              0   (in place: 602, dec: 1)
>  calloc|       5410         574519              0
>    free|      33371        2559108
> 
> Histogram for block sizes:
>     0-15          12775  25% ====================================
>    16-31          17349  34% ==================================================
>    32-47           5369  10% ===============
>    48-63           6057  12% =================
>    64-79           4402   8% ============
>    80-95            371  <1% =
> 
> Graph with pools enabled:
>   http://pobox.com/~hp/gtk-demo-memusage.png
> 

Ok, so an "ideal" gtk+ tuned allocator allocates 0-32 byte really fast,
probably optimises for 32-64 byte allocatins and doesn't really care about
the rest.

> All kind of hard to use without call stack information.
> 
> Would a malloc() tuned for this histogram be faster than generic libc
> malloc(), or is libc malloc tuned for this sort of pattern already?
> 

Sure. You can build a custom allocator on top of standard ones that
optimises for known parameters - there are papers on how to. minimising
number of locks may be more important though.

> Havoc
> 

	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