<br><br><div class="gmail_quote">On Mon, Aug 15, 2011 at 1:03 PM, Marco van de Voort <span dir="ltr"><<a href="mailto:marcov@stack.nl">marcov@stack.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div><div></div><div class="h5">In our previous episode, Max Vlasov said:<br>
> about collecting some statistics.<br>
><br>
> The idea is similar to some disk utilities that collects and sort the sizes<br>
> of directories. You know when every folder on the computer is scanned and<br>
> all the resulting paths are sorted by the summed size. Such utilities<br>
> usually help to find space on the hard drive to free.<br>
><br>
....<br>
<br>
</div></div>This is basically what valgrind (or fulldebugmode of fastmm) does. But they<br>
do this by parsing the stack on each call to the memory manager, and then<br>
keep track of it.<br>
<br>
Note that all these techniques can be very, very slowing. E.g. I tried to debug<br>
the CHM support with valgrind, and I terminated the valgrind process after 5<br>
hours because it was not even half way to where the bug was.<br>
<br>
Without valgrind the program reached the point in 1-2 minutes.....<br>
<br></blockquote></div><br><br>Thanks, I suspected that it's already implemented and that it should be very slow :)<br>But looking at your numbers, if one implements something and finds a way to decrease this 150x factor  (300 min/2min=150), the tool will be more useful <br>

<br><br><div class="gmail_quote">On Mon, Aug 15, 2011 at 1:17 PM, Ludo Brands <span dir="ltr"><<a href="mailto:ludo.brands@free.fr">ludo.brands@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div><div class="h5"><br>
</div></div>The valgrind massif tool (valgrind --tool=massif) does the same but reports<br>
on a sampling basis. It'll look at the heap used and report who allocated<br>
what on a cumulative basis. It won't trace every call nor report leaks but<br>
it allows you to track the big users quite well. I'm currently tracking the<br>
memory "eaters" in lazarus with it. It slows down the program but with a<br>
factor 5 to 10 which makes it more practical than valgrid itself.<br>
<br>
</blockquote></div><br>if there's a common ancestor allocating something (let's call it NewBlock() and it uses GetMem) and I have many descendants using this method, is there a chance to find the "eater" amongst these descendants or massif tool will drop all the stats to NewBlock()?<br>

<br>Max<br><br><br>