I regularly hear complaints online about D's GC being slow or not decent, but those complaints rarely include details.
I've twice seen Walter explain some tradeoffs that were made in the design and implementation of the D GC. [One was on the forum]. [Another on reddit], where he wrote:
"You can make a moving GC with D, it's called a "mostly copying" collector. The trick is to not move things that may have a pointer to them."
and
"Certain GCs instrument the generated code with write gates which notify the GC when memory writes are being made. GC-focused languages rely on this to make the GC better, at the cost of lower performance in the native code.
D has a GC, but is not a GC focused language. The performance cost of write gates is an unacceptable compromise in the context of D."
***
The [D GC page](https://dlang.org/spec/garbage.html) may need a section describing these tradeoffs that were made in the design and implementation of the GC so people can easily see why it is the way it is. That may help avoid regurgitated complaints of "it's too slow" and provide a link to point those folks to.
[One was on the forum]: https://forum.dlang.org/post/[email protected]
[Another on reddit]: https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d/
Comment #1 by michael — 2018-02-15T09:57:17Z
It would be great to have a page on the dlang website tackling the stigma associated with the garbage collector. We can demo some performance benchmarks, perhaps, as well as discuss things to keep in mind. Most importantly, use it to highlight all of the nice features it enables like dynamic arrays as a language feature etc.