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
