禁用D的GC是否“没问题”？

Question

我正在为我创建的字节代码编写解释器，它需要非常快，为此，我不希望GC成为瓶颈，因此我使用GC.disable();禁用了它

但我经常在互联网上读到D的库要求GC存在，但是我没有使用很多库，我的问题是，如果我使用以下模块中的以下内容，是否需要GC：

来自std.conv的
1. to
来自std.algorithm的
2. canFind
来自std.file 的
3. file.read 来自std.stdio的
4. File

我在我的程序中使用上述模块的上述功能，前提是禁用GC是否安全？

Answer 1

您误解了禁用GC的功能。 除非您真正将其编译出来，否则GC将始终可用于例如新。

现在有一些关于GC如何工作的基础知识，当你分配新的内存时，它必须确定它是否可以分配，如果它不能，它必须尝试清理现有的内存才能分配。所以对于D的GC，只要有分配就可以继续收集。现在禁用GC只会阻止它继续进行并在分配时进行收集。你总是可以手动鼓动它这样做。

对于解释器，只要您阻止分配（重用内存），您甚至不需要禁用GC以防止它减慢速度。所以请记住规则，“大”分配并重用该内存！

Answer 2

如果您只是想避免调用垃圾收集，那么诀窍就是不要为GC清理创建任何对象。值得庆幸的是，D有一个属性，将在编译时检查，以确保您不会意外地创建任何垃圾：@nogc

在http://ddili.org/ders/d.en/functions_more.html

上有一个很好的描述

Answer 3

另请注意，您可以重新打开垃圾收集器，让它收集，然后在解释器空闲时再将其关闭。我在D中制作游戏时使用这种技术。它完美无缺。

// Run the GC when we want
core.memory.GC.enable();
core.memory.GC.collect();
core.memory.GC.disable();