bso*_*aid 9 c++ performance unmanaged managed
我正在编写一个非常高性能的应用程序,每毫秒处理和处理数百个事件.
Unmanaged C++比托管c ++更快吗？为什么？
托管C++处理CLR而不是OS和CLR负责内存管理,这简化了代码,并且可能比非托管C++中"程序员"编写的代码更有效？还是有其他原因？当使用托管时,如果对程序员透明并由CLR处理,那么如何避免动态内存分配(这会导致性能损失)？
回到我的问题,托管C++在速度方面是否比非托管C++更有效？为什么？
对此没有一个答案.作为一个非常普遍的规则,本机代码通常会更快,但1)情况并非总是如此,2)有时差异太小而无法关注,3)编写代码的程度通常会比管理代码更大与非托管.
托管代码在虚拟机中运行.基本上,您从一个生成字节代码作为输出的编译器开始,然后将其提供给虚拟机.然后,虚拟机将其重新编译为机器代码并执行该代码.在某些情况下,这可以提供一些真正的优势.举一个例子,如果你有一个运行64位VM的64位处理器(差不多已经给定了)但是在64位处理器之前编写的旧程序很常见,VM仍然会将该字节代码编译为64-位机代码,它可以为至少一些代码提供相当大的速度优势.
同时,对于某些代码来说,它也可能是一个相当明显的缺点.特别是,编译器在用户等待时运行.为了适应这种情况,VM的编译器本身运行速度非常慢.尽管本机代码生成器有所不同,但是您选择的本机编译器至少包含一些在VM的字节码编译器中已经放弃的优化以保持其资源使用合理性的可能性非常大.
VM还使用垃圾收集器.垃圾收集器与手动管理内存具有相当不同的特性.对于许多手动管理器,分配内存相当昂贵.释放内存相当便宜,但与您发布的项目数量大致呈线性关系.其他手动管理人员大致反过来说,在释放内存时做额外的工作以便更快地进行分配.无论哪种方式,成本结构都不同于典型的收集器.
使用垃圾收集器,分配内存通常非常便宜.对于典型的(复制)收集器,释放内存的成本主要取决于已分配且仍然(至少可能)使用的对象的数量.
分配本身也有所不同.在本机C++中,您通常在堆栈上创建大多数对象,其中分配和释放内存都非常便宜.在托管代码中,您通常会动态分配更大比例的内存,并在其中进行垃圾回收.