Any way to track memory allocations?

Jarrett Billingsley jarrett.billingsley at gmail.com
Tue Feb 24 09:35:36 PST 2009


On Tue, Feb 24, 2009 at 12:00 PM, wade Shen <swadenator at gmail.com> wrote:
> I'm writing some performance sensitive code (real time processing) for which I've tried to minimize the number of memory allocations by using preallocated objects pools.  Unfortunately, during the course of running, it seems that lots of memory is still getting allocated even though all explicit "new" and array slicing operations have been moved out of the main processing loops.  As a result the program is quite slow when garbage collection is enabled (but very fast otherwise).

Array slicing does not cause the GC to run.  It is essentially free,
which is a wonderful thing.

> Is there a way to track down where memory is being allocated if I'm using phobos? Any recommendations would be appreciated.

This is something I have *always* wanted.  Unfortunately I don't think
it's possible to add such instrumentation without modifying and
recompiling Phobos.  Even if you're using D2, which uses druntime,
there's no such thing.

Hm, actually..

If you *are* using D2, you might be able to replace the GC interface
with a "debug" interface that just forwards calls to the normal GC.
This is a capability druntime inherited from the Tango runtime - the
GC is separated from the rest of the standard library and can actually
be replaced at link-time.  I don't know if D2 links all three parts of
druntime into a single library or not, though.

Here are some other things that could be causing allocation:

- Array appending (~=) can cause it; array concatenation (~) is
guaranteed to cause it.
- Array .dup.
- Adding items to associative arrays.
- In D2, nested functions/anonymous delegates can allocate memory
secretly, unless you're careful and only pass them to "scope" delegate
parameters.


More information about the Digitalmars-d-learn mailing list