Re: RAM consumption when working with the gcc repo
- From
- Marco Costalba <mcostalba@gmail.com>
- Date
- Dec 8, 2007, 19:12 UTC
- Message-ID
- <e5bfff550712081112xf34eb1cua95da3f9397030f0@mail.gmail.com>
- In-Reply-To
- <Pine.LNX.4.64.0712081153500.27959@racer.site>
On Dec 8, 2007 12:54 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 10 quoted lines
> > > > BTW does exist a tool to profile memory consumption by each source level > > struct / vector/ or any other data container? > > > > Valgrind checks mainly memory leaks, callgrind gives profiling > > information in terms of call graphs and times/cycles consumed by each > > function. > > Have you looked at Massif (also part of Valgrind)? >
Only very quickly, so probably I've missed something, but anyway that's my comment on Massiv:
- Interesting output is in html format, graph is nice but gives very general info.
- The tool mainly tracks who called malloc and friends also going back in the stack frame (in my box if I try to set stack deep at 4 instead of default 3 program crashes)
- Does not seem to give information regarding the structures where memory is allocated, only the function names that allocate directly or indirectly the memory. Nothing like
struct my_data has 34.256 instantiations struct stuff has 2.456 instantiations
- Relation between memory and time of allocation is IMHO a little bit confusing, it's like a parameter obtained from multipling allocated bytes x time, not very useful.
- Regarding the previous point, it seems missing a way to trigger/snapshotting the memory map in terms of source level structures used by the application in a given time, triggable through code.
Just to be clear, the much better callgrind tool allows to insert in the code the macros
CALLGRIND_START_INSTRUMENTATION and CALLGRIND_STOP_INSTRUMENTATION
that start/stop recording of events in the code ranges specified by the developer. What it seems to be missing in massif it's a macro like
MASSIV_SNAPSHOT_MEM_MAP
to be used _where_ developer needs and that gives information on heap allocation in terms of source level entities that *use* that memory, not low level addresses or allocator functions.
Thanks Marco