我正在考虑将d用于我正在进行的图形引擎。让我失望的一件事是GC。
我还是一名年轻的程序员，我可能对GC有很多误解，我希望你能澄清一些问题。
我的目标是低延迟，一般来说时间至关重要。据我所知，GC是非常不可预测的，例如我的应用程序可以每16.6ms渲染一帧，到GC的时候它可以达到任何数字，如30ms，因为它不是确定性的吗？
我读到你可以在D中关闭GC，但是你不能使用D的大部分标准库而且GC没有完全关闭。这是真的吗？
你认为在时间关键的应用中使用D是否有意义？
答案 0 :(得分：8)
简短回答：如果您不是经验丰富的D开发人员，则需要进行大量自定义，并且非常困难。
问题列表：
内存管理本身并不是一个大问题。在实时应用程序中，您永远不想在主循环中分配内存。为所有主数据预先分配内存池实际上是执行此类应用程序的标准方法。在这个意义上，D没有什么不同 - 你仍然直接调用C malloc为你的池获取一些堆，这个内存不会由GC管理，它甚至都不知道它。
但是，某些语言功能和Phobos的大部分功能都会自动使用GC 。例如，如果没有某种形式的自动管理分配，您无法真正连接切片。 Phobos在相当长的一段时间内根本没有强有力的政策。
由于大多数使用的内存无论如何都通过池进行管理，因此很少有语言触发的分配本身不会成为问题。但是，库存中的实时软件存在一个杀手级问题：默认D垃圾收集器是世界末日。即使几乎没有垃圾，当收集周期运行时，整个程序也会遇到延迟峰值，因为所有线程都会被阻塞。
可以做些什么：
1）使用GC.disable();关闭收集周期。它将解决世界问题，但现在你的程序将在某些情况下开始泄漏内存，因为基于GC的分配仍然有效。
2）转储隐藏的GC分配。有-vgc切换的拉取请求，我现在找不到，但在它缺席的情况下，您可以编译自己的druntime版本，在gc_malloc()调用时打印回溯。您可能希望将其作为自动测试套件的一部分运行。
3）完全避免使用Phobos并使用类似https://bitbucket.org/timosi/minlibd的替代方法。
所有这些应该足以满足游戏开发者典型的软实时要求，但正如您所看到的那样，它并不简单，需要逐步淘汰D分发。
未来替代方案：
一旦Leandro Lucarella将他的concurrent garbage collector移到D2（计划但未安排），情况将变得更加简单。即使不禁用GC，少量GC管理的内存+并发实现也可以满足软实时要求。甚至Phobos也可以在从最烦人的分配中剥离后使用。但我认为不会很快发生。
但是硬实时呢？
你最好不要尝试。但这是另一个要讲述的故事。
答案 1 :(得分：2)
如果你不喜欢GC - 禁用它。
以下是：
import core.memory;
void main(string[] args) {
GC.disable;
// your code here
}
当然，你必须自己做内存管理。它是可行的，有几篇关于它的文章。这里也讨论过，我只是不记得线程了。
dlang.org也有关于此的有用信息。这篇文章http://dlang.org/memory.html涉及实时编程的主题，您应该阅读它。