GC vs. Manual Memory Management Real World Comparison

Rob T rob at ucora.com
Wed Oct 24 11:26:47 PDT 2012


On Wednesday, 24 October 2012 at 12:21:03 UTC, Paulo Pinto wrote:
>
> Having dealt with systems programming in languages with GC 
> (Native Oberon, Modula-3), I wonder how much an optional GC 
> would really matter, if D's GC had better performance.
>
> --
> Paulo

Well, performnce is only part of the GC equation. There's 
determinism, knowing when the GC is invoked and ability to 
control it, and increased complexity introduced by a GC, which 
tends to increase considerably when improving the GCs performance 
and ability to manage it manually. All this means there's a lot 
more potential for things going wrong, and this cycle of fixing 
the fix may never end.

The cost of clinging onto a GC may be too high to be worth 
relying on as heavily as is being done, and effectivly forcing a 
GC on programmers is the wrong approach because not everyone has 
the same requirements that require its use. When I say "forcing", 
look at what had to be done to fix the performance of the game in 
question, what was done to get rid of the GC was a super-human 
effort and that is simply not a practical solution by any stretch 
of the imagination.

A GC is both good and bad, not good for everyone and not bad for 
everyone, with shades of gray in between, so it has to be made 
fully optional, with good manual control, and easily so.

--rt



More information about the Digitalmars-d-announce mailing list