c++ - 托管 C++ 与非托管/ native C++ 的性能对比

Question

我正在编写一个非常高性能的应用程序，每毫秒处理和处理数百个事件。

非托管 C++ 是否比托管 C++ 更快？为什么？

托管 C++ 处理 CLR 而不是操作系统，CLR 负责内存管理，这简化了代码并且可能比“程序员”在非托管 C++ 中编写的代码更高效？还是有其他原因？使用托管时，如果动态内存分配对程序员来说是透明的并由 CLR 处理，那么如何避免动态内存分配导致性能下降？

回到我的问题，托管 C++ 在速度方面是否比非托管 C++ 更高效，为什么？

Answer 1

没有人回答这个问题。作为一个真正的一般规则， native 代码通常会更快，但 1) 情况并非总是如此，2) 有时差异太小而无需关心，以及 3) 代码编写得如何通常会比托管与非托管产生更大的差异。

托管代码在虚拟机中运行。基本上，您从生成字节码作为输出的编译器开始，然后将其提供给虚拟机。然后虚拟机将其重新编译为机器码并执行。这在某些情况下可以提供一些真正的优势。例如，如果您有一个运行 64 位 VM 的 64 位处理器(几乎不再是给定的)，但是在 64 位处理器普遍存在之前编写的旧程序，VM 仍会将该字节代码编译为 64-位机器代码，它至少可以为某些代码提供相当大的速度优势。

同时，对于某些代码来说，这也是一个相当明显的缺点。特别是，编译器在用户等待时正在运行。为了适应这种情况，VM 的编译器本身不能运行得很慢。尽管 native 代码生成器各不相同，但很有可能您选择的任何 native 编译器都至少包含一些在 VM 的字节码编译器中放弃的优化，以保持其资源使用合理。

VM 还使用垃圾收集器。垃圾收集器与手动管理内存具有相当不同的特征。对于许多手动管理器，分配内存相当昂贵。释放内存相当便宜，但与释放的项目数量大致呈线性关系。其他手动管理器大致相反，在释放内存时做额外的工作以使分配更快。无论哪种方式，成本结构都不同于典型的收集器。

使用垃圾收集器，分配内存通常非常便宜。对于典型的(复制)收集器，释放内存的成本主要取决于已分配且仍在(至少可能)在使用中的对象的数量。

虽然分配本身也不同。在 native C++ 中，您通常在堆栈上创建大多数对象，其中分配 和 释放内存都非常便宜。在托管代码中，您通常会动态分配更大比例的内存，用于垃圾收集。