D Language 2.0

[dsimcha]

== Quote from Craig Black (craigblack2 at 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().