GC vs. Manual Memory Management Real World Comparison

[Rob T]

On Tuesday, 23 October 2012 at 16:30:41 UTC, Benjamin Thaut wrote:
> Here a small update:
>
> I found a piece of code that did manually slow down the 
> simulation in case it got to fast. This code never kicked in 
> with the GC version, because it never reached the margin. The 
> manual memory managed version however did reach the margin and 
> was slowed down. With this piece of code removed the manual 
> memory managed version runs at 5 ms which is 200 FPS and thus 
> nearly 3 times as fast as the GC collected version.
>
> Kind Regards
> Benjamin Thaut

That's a very significant difference in performance that should 
not be taken lightly. I don't really see a general solution to 
the GC problem other than to design things such that a D 
programmer has a truely practical ability to not use the GC at 
all and ensure that it does not sneak back in. IMHO I think it 
was a mistake to assume that D should depend on a GC to the 
degree that has taken place.

The GC is also the reason why D has a few other significant 
technical problems not related to performance, such as inability 
to link D code to C/C++ code if the GC is required on the D side, 
and inability to build dynamic liraries and runtime loadable 
plugins that link to the runtime system - the GC apparently does 
not work correctly in these situatons, although the problem is 
solvable how this was allowed to happen in the first place is 
difficult to understand.

I'll be a much more happy D programmer if I could guarantee where 
and when the GC is used, therefore the GC should be 100% optional 
in practice, not just in theory.

--rt