Re: Memory profiling
- From: "Alex R. Mosteo" <devnull@xxxxxxxxxxxxxx>
- Date: Fri, 27 May 2005 17:55:46 +0200
Robert A Duff wrote:
"Alex R. Mosteo" <devnull@xxxxxxxxxxxxxx> writes:
I suppose something similar can be achieved using distinct storage pools for each access type being tracked, but I find this more inconvenient. Ummm, maybe a type holding a list of storage pools created on demand...
All those storage pools can share the same underlying memory pool. That is, each pool just keeps track of whatever debugging/statistics info you want, and then calls some underlying pool, or just does a "new", or calls malloc, or whatever. So gathering fine-grained (per type) information does not need to imply that you have to actually allocate type-segregated data.
That's the idea I had in mind, but you still have to provide a new storage pool for each tracked access type. Nonetheless, I see interesting potential in this idea.
In other news, I've just tested the Massif module of Valgrind and while it doesn't do exactly what I wanted, it is a very valuable tool. What it does is to keep track of all allocations, so it gives and idea of the overall story instead of a particular moment in time. It works out-of-the-box with gnat executables compiled with debug info.
And I just have recalled about gnatmem, silly me. .
- Follow-Ups:
- Re: Memory profiling
- From: Alex R. Mosteo
- Re: Memory profiling
- References:
- Memory profiling
- From: Alex R. Mosteo
- Re: Memory profiling
- From: Robert A Duff
- Memory profiling
- Prev by Date: Re: Memory profiling
- Next by Date: Re: Memory profiling
- Previous by thread: Re: Memory profiling
- Next by thread: Re: Memory profiling
- Index(es):
Relevant Pages
|