Significant GC performance penalty

[H. S. Teoh]

On Fri, Dec 14, 2012 at 08:27:46PM +0100, Paulo Pinto wrote:
[...]
> - Having GC support, does not mean to do call new like crazy, one
> still needs to think how to code in a GC friendly way;

It makes me think, though, that perhaps there is some way of optimizing
the GC for recursive data structures where you only ever keep a
reference to the head node, so that they can be managed in a much more
efficient way than a structure where there may be arbitrary number of
references to anything inside. I think this is a pretty common case, at
least in the kind of code I encounter frequently.

Also, coming from C/C++, I have to say that my coding style has been
honed over the years to think in terms of single-ownership structures,
so even when coding in D I tend to write code that way. However, having
the GC available means that there are some cases where using multiple
references to stuff will actually improve GC (and overall) performance
by eliminating the need to deep-copy stuff everywhere.


> - GC enabled languages runtimes usually offer ways to peak into the
> runtime, somehow, and allow the developer to understand how GC is
> working and what might be improved;
[...]

Yeah, I think for most applications, it's probably good enough to use
the functions in core.memory (esp. enable, disable, collect, and
minimize) to exercise some control over the GC so that you can use
manual memory management in the important hotspots, and just let the GC
do its thing in less important parts of the program. I think
core.memory.minimize will solve the OP's concern about GC'd apps having
bad memory footprints.


T

-- 
Computers aren't intelligent; they only think they are.