我无法在现实生活中找到关于ARC性能影响的客观研究. 官方文件说
编译器有效地消除了许多无关的保留/释放调用,并且已经投入了大量精力来加速Objective-C运行时.特别是,当方法的调用者是ARC代码时,常见的"返回保留/自动释放对象"模式要快得多,并且实际上并不将对象放入自动释放池中.
由技术爱好者传播/变形为"ARC更快".
我所知道的就是我所测量的.我们最近将我们的iOS项目迁移到了ARC,我在代码的一些CPU密集区域之前/之后进行了一些性能测量(生产代码,-Os当然是用标志编译的).
我观察到70%(是70%)的性能回归.使用Instruments跟踪保留/释放事件,我意识到编译器在你不会这样做的区域引入了很多保留/释放对(在ARC之前的环境中).基本上,任何临时变得强大.也就是说,我相信,性能回归的来源.
迁移之前的原始代码已经非常优化.几乎没有任何自动释放.因此,切换到ARC几乎没有改进的余地.
幸运的是,Instruments能够向我展示ARC引入的最昂贵的保留/释放,并且我能够使用__unsafe_unretained来停用它们.这略微减轻了性能回归.
是否有人有关于此技术或其他技术的任何信息以避免性能损失？(除了停用ARC)
谢谢.
编辑:我不是说ARC因为性能影响而坏.使用ARC的优势在很大程度上优于性能回归(在我们的代码中,回归没有任何明显的效果,所以我放手了).我认为ARC是一项非常好的技术.我永远不会回到MRC.我好奇地问这个问题.
我只是对这个主题的绝大多数博客(比如这里 和那里)略微恼火,或多或少给人的印象是ARC代码会比MRC代码更快(我之前我相信的事情是我把它放在它上面).而且我确实感觉在某些微观基准测试之外并非如此.充其量你可以希望与MRC相提并论,而不是更快.我做了一些其他涉及对象操作的简单测试(比如计算文档中的单词).每次ARC都比较慢(认为不像我最初谈论的70%的回归那样糟糕)
\ {开始嘲讽}
事实上,上述文档确实回答了这个问题:
ARC慢吗？
这取决于你测量的是什么,但通常是"不".
显然应该理解为
\ {开始模仿}
嗯......哼......我们不能说它慢一点,因为这是一个新的酷技术,我们希望你采用它.所以我们用双引号回答"否"只是为了避免集体诉讼.并停止问愚蠢的问题.
\ {端模仿}
\ {端讽刺}