Hunting down rogue memory allocations?

Gary Willoughby via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Oct 2 14:26:17 PDT 2014


On Thursday, 2 October 2014 at 20:31:29 UTC, Kiith-Sa wrote:
> 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).

Great thanks, I'll look into those.


More information about the Digitalmars-d-learn mailing list