垃圾回收的演示比手动内存管理更快

我已经在很多地方读取（赫克，我甚至写了那么我自己），垃圾回收可能（理论上）比手工内存管理更快。

但是，展示要比讲讲难得多。
我从未真正看到过任何代码可以证明这种效果。

是否有人拥有（或知道在哪里可以找到）证明这种性能优势的代码？

请参阅http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx，并通过所有链接查看Rico Mariani和Raymond Chen（微软的非常有能力的程序员）对决。雷蒙德将改进非托管服务器，雷科将通过优化托管服务器中的相同内容进行响应。

借助几乎为零的优化工作，托管版本的启动速度比手册快了很多倍。最终，手册击败了托管人员，但只能通过优化到大多数程序员都不想达到的水平。在所有版本中，该手册的内存使用情况均比托管版本好得多。

经验法则是没有免费的午餐。

GC消除了手动内存管理的麻烦，并减少了犯错误的可能性。在某些情况下，某些特定的GC策略是解决该问题的最佳解决方案，在这种情况下，您无需为此付出任何代价。但是在其他解决方案中，其他解决方案将更快。由于您始终可以从较低的级别模拟较高的抽象，但是不能反过来进行，因此可以有效地证明，在一般情况下，较高的抽象不可能比较低的抽象更快。

GC 是手动内存管理的特例

要手动获得更好的性能可能需要大量工作或更多错误，但这是另一回事。

容易构造一种人为的情况，在这种情况下，GC的效率要比手动方法高得多-只需安排垃圾收集器只有一个“根”，并且一切都是垃圾，因此GC步骤立即完成。

如果您考虑一下，那就是在垃圾回收分配给进程的内存时使用的模型。进程死了，它所有的内存都是垃圾，我们完成了。即使实际上，启动，运行和死亡的过程也不会留下任何痕迹，这比永久启动和运行的过程更有效率。

对于用带有垃圾回收的语言编写的实用程序，垃圾回收的优点不是速度而是正确和简单。

应该考虑GC不仅仅是一种内存管理策略；它还对语言和运行时环境的整个设计提出了要求，这带来了成本（和收益）。例如，必须将一种支持GC的语言编译成一种形式，在这种形式下，指针不能从垃圾收集器中隐藏起来，并且通常只有通过精心管理的系统原语才能构造指针。另一个考虑因素是难以维持响应时间保证，因为GC强制执行了一些步骤，这些步骤必须被允许完成。

因此，如果您使用的语言是垃圾回收，并且将速度与同一系统中的手动管理的内存进行比较，那么即使您不使用垃圾回收，您仍然必须付出开销来支持垃圾回收。

更快是可疑的。但是，如果受硬件支持，它可以是超快，不易察觉或更快的。很久以前就有针对LISP机器的设计。有人将GC内置到硬件的内存子系统中，这样主CPU不知道它在那里。像许多后来的设计一样，GC与主处理器同时运行，几乎不需要暂停。更现代的设计是Azul Systems Vega 3机器，其运行Java代码的速度比使用专用处理器和无中断GC的JVM快。如果您想知道GC（或Java）的速度有多快，请使用Google。

我对此做了很多工作，并在此处进行了描述。我用C ++对Boehm GC进行了基准测试，使用malloc但没有释放，使用分配和释放以及使用freeC ++编写的自定义标记区域GC进行分配，而OCaml的普通GC运行的是基于列表的n皇后求解器。在所有情况下，OCaml的GC都更快。故意编写C ++和OCaml程序以执行相同顺序的相同分配。

当然，您可以重写程序以仅使用64位整数而无需分配来解决问题。尽管速度更快，但会失败。（这是为了预测我正在使用C ++内置的原型在研究新的GC算法的性能）。

我在行业中花费了很多年，将真正的C ++代码移植到托管语言中。在几乎每种情况下，我都观察到性能上的实质性改进，其中许多可能是由于GC胜过了手动内存管理。实际的局限性不是可以在微基准测试中完成的，而是可以在截止日期之前完成的，而基于GC的语言可以极大地提高生产率，我从未回过头。我仍然在嵌入式设备（微控制器）上使用C和C ++，但即使现在这种情况也正在改变。

这样的例子必然具有不良的手动存储器分配方案。

假设最好的垃圾收集器GC。它在内部具有分配内存，确定可以释放哪些内存的方法以及最终释放内存的方法。这些在一起花费的时间比所有的时间少GC; 在其他方法上花费了一些时间GC。

现在考虑一个使用与相同的分配机制的手动分配器，该分配器GC的free()调用只是预留要通过与相同的方法释放的内存GC。它没有扫描阶段，也没有任何其他方法。它必然需要更少的时间。