garbage-collection - 可以始终调用 core.memory 的 GC.collect 以获得更一致的帧速率吗？

Question

我正在考虑使用 OpenGL 和 D 制作实时游戏，但我担心垃圾收集器。据我所知，这是一种可能性:

• 运行 10 帧
• 垃圾收集器运行自动启动并运行 10 毫秒
• 运行 10 帧
• 垃圾收集器运行自动启动并运行 10 毫秒
• 运行 10 帧
• 等等

这可能很糟糕，因为它会导致口吃。但是，如果我强制垃圾收集器持续运行，就像使用 GC.collect 一样，它会让我的游戏更流畅吗？像这样:

• 运行 1 帧
• 垃圾收集器运行 1-2 毫秒
• 运行 1 帧
• 垃圾收集器运行 1-2 毫秒
• 运行 1 帧
• 等等

这种方法真的会奏效并使我的帧速率更加一致吗？我想使用 D，但如果我不能使我的帧速率保持一致，那么我将不得不使用 C++11。

我意识到它可能效率不高，但重要的是它会更流畅，帧率更一致。如果你明白我的意思，我宁愿有一个平滑的 30 fps 而不是口吃的 35 fps。

Answer 1

是的，但它可能不会产生显着差异。

在 GC 周期中花费的大部分时间是“标记”阶段，其中 GC 从根区域(静态数据、TLS、堆栈和寄存器)传递地访问每个分配的内存块(已知包含指针) )。

有几种方法可以优化应用程序的内存，以使 D 的 GC 对性能的影响更小:

• 使用批量分配(将对象批量分配为数组)
• 使用自定义分配器(std.allocator 即将推出，但您可以使用自己的或第三方的解决方案)
• 使用手动内存管理，就像在 C++ 中一样(您可以像使用 shared_ptr 一样使用 RefCounted)
• 在游戏过程中完全避免内存分配，而是预先分配所有内容
• 禁用 GC，并在更方便的时候手动运行集合

一般来说，我不建议在编写任何代码之前关注 GC。 D 提供了避免大量 GC 分配的工具。如果您保持较小的托管堆，GC 周期可能不会花费足够长的时间来干扰您的应用程序的响应能力。