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.
