Hunting down rogue memory allocations?

[Kiith-Sa via Digitalmars-d-learn]

On Thursday, 2 October 2014 at 20:16:56 UTC, Gary Willoughby 
wrote:
> Say i have created a program written in D, what tools are 
> available for me to track memory allocations?
>
> If you write a program and its performance is slow because you 
> suspect too many allocations are taking place in unrecognised 
> areas, what tools or techniques do you use to find where they 
> are and eliminate them?

If *time* spent by allocations is a problem, profile with `perf 
top` (assuming you have Linux): Look for 'gc', 'malloc', 
'calloc', etc.
(Plain perf record will also work, but not be as 
quick/interactive. CodeXL works too.)

See https://perf.wiki.kernel.org/index.php/Tutorial - you 
probably need some specific arguments to get caller info, didn't 
use it for a while so I don't remember.

If e.g. the GC is an issue, it should be immediately evident with 
some GC function taking e.g. over 5% of time. Usually the actual 
overhead will be much higher but divided into multiple smaller 
functions that will take little time individually. Drill down 
into one of these and look at its callers. Eliminate the most 
common source of calls, look again, repeat. Usually removing a 
source of alloc calls will result in better speedup than the 
profiler suggests.



If *space* is a problem, Valgrind doesn't work with most D 
programs for some reason (probably D's fault), so, good luck with 
that. But eliminating the biggest time wasters usually helps 
space as well (or rather, it makes it more controllable as you 
know better where you allocate memory).