Suggestion: add a new option displaying 'malloc' function call counts

[GoogleCodeExporter]

It would be very useful if pprof would have an option when it would also
display number of malloc calls that each procedure corresponding to each
leaf node performed.

This would be very useful for performance analysis since high-performance
programs should avoid too frequent allocations of very small memory blocks.

I assume it shouldn't be very difficult to do. And such information is very
relevant to the major purpose of perftools.

Actually Valgrind's tool callgrind can display call counts. But it slows
the run over 100X and perftools slows the run down much less.

Original issue reported on code.google.com by visa_des...@yahoo.com on 16 Apr 2008 at 4:34

[GoogleCodeExporter]

Duly noted, but it's unlikely we'll get to this ourselves.  But feel free to
implement something to that effect if you'd like!  It should be pretty easy to 
get
that information with the sampling in tcmalloc.cc -- in fact, if you set the 
sample
rate high enough, the data is probably all right there already, and you just 
need to
figure out a way to extract it.

Original comment by csilv...@gmail.com on 17 Apr 2008 at 12:42

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Another option, even simpler, would be to just use gprof (compile with -pg).  
That
shouldn't slow down the program very much.  Of course, you'd have to have 
access to
the source code.

Original comment by csilv...@gmail.com on 17 Apr 2008 at 12:49

• Changed state: WontFix

[GoogleCodeExporter]

Another observation: I think this functionality is already available via the
heap-profiler.  If you get a heap profile for your program, and then run pprof 
with
--alloc-objects, it should give you information about the number of objects 
allocated
(rather than their size), which I believe is what you're asking for.  Or
--inuse-objects if you're interested in seeing stuff that was never freed.

Note this is still sampling-based, so not 100% accurate numbers, but should be 
good
for the kind of thing you're trying to do.

Original comment by csilv...@gmail.com on 17 Apr 2008 at 10:22