Re: memory allocations.

[Havoc Pennington <hp redhat com>]

Ulrich Drepper <drepper redhat com> writes:
> Sander Vesik <sv117949 ireland sun com> writes:
> 
> > But we definately need to have a size/frequency distribution graphs for
> > common applications and use patterns first before doing anything.
> 
> Well, run
> 
>   memusage <program> <arguments>...
>

Here is memusage run on the test I was memprofing, with mem pools
disabled. Results are quite different from memprof, not sure if it's a
difference in specification of what's being counted or just memprof
being screwy.

First with --disable-mem-pools which replaces mem pool blocks with
single calloc() calls for debugging:

$ memusage gtk-demo

Memory usage summary: heap total: 3612535, heap peak: 1004755, stack
peak: 17308
         total calls   total memory   failed calls
 malloc|      43521        2317408              0
realloc|       4269         598560              0   (in place: 590, dec: 1)
 calloc|      18220         696567              0
   free|      41895        2645808
Histogram for block sizes:
    0-15          28880  43% ==================================================
   16-31          17489  26% ==============================
   32-47           5497   8% =========
   48-63           6155   9% ==========
   64-79           4444   6% =======
   80-95            372  <1% 

And with mem pools re-enabled:

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

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?

Havoc


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