Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Here are my <a href="http://www.learn-cocos2d.com/2013/03/confirmed-arc-slow/" rel="nofollow noreferrer">ARC vs MRC performance measurements</a>. The performance test project is <a href="https://github.com/LearnCocos2D/LearnCocos2D/tree/master/Cocos2D-ARC-Performance-Test" rel="nofollow noreferrer">available on github</a> so you can add your own tests. Just be sure to run it on a device. The results in the Simulator are skewed, and often in favor of MRC.</p> <p>To summarize:</p> <p><strong>ARC and MRC are generally the same speed</strong>. In general code should be faster under ARC, but tight loops can be slower and significantly so.</p> <p>In low-level tests ARC has an edge over MRC speed-wise, due to optimizations (autorelease returns, @autoreleasepool). </p> <p>There is some code where ARC inserts additional retain/release that would not strictly be necessary under MRC, as long as the app is single-threaded. Such code may be slower under ARC, though it only makes a difference in tight loops and depends a lot on the code in question.</p> <p>For example a method receiving an object should retain it even under MRC, because it might be released in a multithreaded application while the method is running. The fact that you can omit that code in MRC makes it faster, but inherently unsafer (although you'll rarely run into such an issue, OTOH if you do you wish you hadn't). Example:</p> <pre><code>-(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 } </code></pre> <p>The genetic algorithm I used in the test project is <strong>roughly 40% slower with ARC</strong> because of this. It is a bad (extreme) example because for an algorithm of that kind you should see far greater performance improvements by rewriting critical code sections in C due to lots of insert/remove operations on NSMutableArray, and NSNumber objects being created.</p> <p><strong>It is downright negligent to dismiss ARC entirely because it <em>can</em> be slower</strong> in some situations. If you find those situations to be performance critical then <code>-fno-objc-arc</code> that code or rewrite it in C.</p> <p>ARC should not be considered for or against because of performance considerations. <a href="https://stackoverflow.com/a/8760820/201863">ARC is a tool that make's a programmer's job a lot easier</a>. It's up to you to decide whether you like wasting time trying to find leaked objects and dangling pointer crashes so much that you'd rather stick to MRC.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload