On Tue, Feb 24, 2009 at 12:00 PM, wade Shen <[email protected]> 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.
