有没有关于使用 ARC 对性能影响的具体研究？

我找不到关于现实项目中 ARC 性能影响的客观研究。官方文档 http://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html says

编译器有效地消除了许多无关的保留/释放调用，并且在总体上加速 Objective-C 运行时方面投入了大量精力。特别是，当方法的调用者是 ARC 代码时，常见的“返回保留/自动释放对象”模式要快得多，并且实际上不会将对象放入自动释放池中。

科技迷们将其转述/变形为“ARC 更快”。

我所确定的就是我所测量的。我们最近将 iOS 项目迁移到 ARC，我在代码的某些 CPU 密集区域（生产代码，使用-Os当然是旗帜）。

我观察到性能下降了 70%（是的，70%）。使用仪器为了跟踪保留/释放事件，我意识到编译器在您不会执行的区域（在 ARC 之前的环境中）引入了很多保留/释放对。基本上，任何暂时的都会变得强大。我相信这就是性能回归的根源。

迁移之前的原始代码已经相当优化。几乎没有完成任何自动释放。因此，改用 ARC 几乎没有改进的余地。

幸运的是，仪器能够向我展示 ARC 引入的最昂贵的保留/释放，并且我能够使用 __unsafe_unretained 停用它们。这稍微减轻了性能下降的影响。

有人有关于此或其他技术的任何信息来避免性能损失吗？ （除了停用 ARC）

Thanks.

编辑： 我并不是因为性能影响而说 ARC 不好。使用ARC的优点很大程度上优于性能回归（在我们的代码中，回归没有任何明显的效果，所以我放弃了）。我认为ARC是一项非常好的技术。我永远不会再回到 MRC。我更多是出于好奇才问这个问题。

我只是对绝大多数关于这个主题的博客有点恼火（比如here http://blog.mugunthkumar.com/articles/migrating-your-code-to-objective-c-arc/ 在那里 http://maniacdev.com/ios-5-sdk-tutorial-and-guide/arc-automatic-reference-counting/）这或多或少给人一种印象，即 ARC 代码将比 MRC 代码更快（在我动手之前我就相信这一点）。我确实有这样的感觉：除了一些微观基准测试之外，情况并非如此。您最多只能希望与 MRC 持平，而不是更快。我做了一些其他涉及对象操作的简单测试（例如计算文档中的单词数）。每次 ARC 都会变慢（我认为没有我最初所说的 70% 性能回归那么糟糕）

\开始{讽刺}

事实上，上述文档确实回答了这个问题：

ARC 慢吗？

这取决于您测量的内容，但通常是“否”。 ...

显然应该理解为

\开始{模仿}

嗯...嗯...我们不能说它更慢，因为这是一项新的很酷的技术，我们希望您采用它。因此，我们用双引号回答“不”，只是为了避免集体诉讼。别再问愚蠢的问题了。

\end{戏仿}

\结束{讽刺}

这是我的ARC 与 MRC 性能测量 http://www.learn-cocos2d.com/2013/03/confirmed-arc-slow/。性能测试项目为可以在 github 上找到 https://github.com/LearnCocos2D/LearnCocos2D/tree/master/Cocos2D-ARC-Performance-Test这样您就可以添加自己的测试。只要确保在设备上运行它即可。模拟器中的结果存在偏差，并且通常有利于 MRC。

总结一下：

ARC和MRC一般速度相同。一般来说，代码在 ARC 下应该会更快，但紧密循环可能会更慢，而且速度明显更慢。

在低级测试中，由于优化（自动释放返回，@autoreleasepool），ARC 在速度方面优于 MRC。

在某些代码中，ARC 插入了额外的保留/释放，只要应用程序是单线程的，这些代码在 MRC 下并不是严格必需的。此类代码在 ARC 下可能会更慢，尽管它只会在紧密循环中产生影响，并且在很大程度上取决于相关代码。

例如，接收对象的方法即使在 MRC 下也应该保留它，因为在该方法运行时它可能会在多线程应用程序中被释放。事实上，您可以在 MRC 中省略该代码，这会使其速度更快，但本质上更不安全（尽管您很少会遇到这样的问题，OTOH，如果您希望没有的话）。例子：

-(void) someMethod:(id)object
{
    [object retain]; // inserted by ARC, good practice under MRC
    [object doSomething];
    [object doAnotherThing];
    [object release]; // inserted by ARC, good practice under MRC
}

我在测试项目中使用的遗传算法是使用 ARC 大约慢 40%因为这。这是一个糟糕（极端）的例子，因为对于这种算法，由于 NSMutableArray 和 NSNumber 对象上创建的大量插入/删除操作，您应该通过用 C 重写关键代码部分来看到更大的性能改进。

完全忽视 ARC 是彻头彻尾的疏忽，因为它can慢一点在某些情况下。如果您发现这些情况对性能至关重要，那么-fno-objc-arc该代码或用 C 重写它。

不应因为性能考虑而考虑赞成或反对ARC。ARC 是一个让程序员的工作变得更加轻松的工具 https://stackoverflow.com/a/8760820/201863。由您来决定您是否喜欢浪费时间尝试查找泄漏的对象和悬空指针崩溃，以至于您宁愿坚持使用 MRC。