== Quote from Craig Black (craigbla...@cox.net)'s article > I would have to agree and this is one of my causes for hesisation in > adopting D. The code I write requires the highest performance possible. I > am concerned that when I port it over to D, I will have to avoid using a lot > of D features that use the GC (built-in arrays, closures, standard library > features, etc.) in order to get the best possible performance. D does not > adhere to the C++ zero-overhead principle, and I see this as a risk. So > if/when I end up porting my code to D I may evolve my own dialect of D that > uses only the subset of features that tend to provide the best performance.
D's garbage collector is admittedly not that good, but there are some pretty important mitigating factors that you should be aware of: 1. You can use your limited dialect only in the performance-critical parts of your code and program in a more Java-style "just allocate whatever needs to be allocated and let it get GC'd whenever it gets GC'd" way in the other 80% of your code. 2. D provides enough low-level features (most importantly the ability to allocate an untyped memory block) that you can write some pretty efficient custom memory management schemes. You can do object pools pretty well. You can do mark-release pretty well. If you're doing a lot of numerics, you can implement a second stack (similar to Andrei's proposed SuperStack, or my TempAlloc) to efficiently allocate temporary workspace arrays. Furthermore, D provides enough abilities to make these hacks well-encapsulated that they start to appear significantly less ugly than they would in C or C++, where the encapsulation would be weaker. 3. You can use C's malloc (or nedmalloc) from D, though you do have to be careful about making sure any region of the C heap that contains pointers into the GC heap is marked with addRange().
