Any way to track memory allocations?

[wade]

Thanks,

That's helpful.  I'm using D 1.0.  I've eliminated all array concats, dups, etc. but there's still a significant amount of memory being allocated that I can't seem to detect.

Perhaps, I can recompile an instrumented version of phobos...

wade

Jarrett Billingsley Wrote:

> 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.