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