18

When I moved to Objective C (iOS) from C++ (and little Java) I had hard time understanding memory management in iOS. But now all this seems natural and I know retain, autorelease, copy and release stuff. After reading about ARC, I am wondering is there more benefits of using ARC or it is just that you dont have to worry about memory management. Before moving to ARC I wanted to know how worth is moving to ARC.

  1. XCode has "Convert to Objective C ARC" menu. Is the conversion is that simple (nothing to worry about)?
  2. Does it help me in reducing my apps memory foot-print, memory leaks etc (somehow ?)
  3. Does it has much testing impact on my apps ?
  4. What are non-obvious advantages?
  5. Any Disadvantage of moving to it?
msk
  • 8,885
  • 6
  • 41
  • 72
  • Are you talking new or existing application? If existing, how much future modification are you anticipating doing (if any)? Relatively straight-forward code, or apt to be doing a bunch of strange things? Pure Objective-C or with C/C++ data structures mixed in? – Hot Licks Mar 26 '12 at 17:12
  • 1
    possible duplicate of [iOS: to ARC or not to ARC? Pros and Cons](http://stackoverflow.com/questions/8760431/ios-to-arc-or-not-to-arc-pros-and-cons) – Brad Larson Mar 26 '12 at 18:37
  • @Brad Larson: This is why I hate questions that consist of many partial questions. – BoltClock Mar 26 '12 at 22:11
  • So many questions like this recently... So many people on the fence! (Me included) – Nicolas Miari Jun 19 '12 at 20:21
  • I have observed that when one codes in ARC one very rapidly loses their "Spidey sense" for dealing with manual retain/release. It's a muscle that atrophies rapidly when not exercised. – Hot Licks Nov 13 '13 at 20:58

7 Answers7

23

Here's my specific take on ARC:

1) XCode has "Convert to Objective C ARC" menu. Is the conversion is that simple (nothing to worry about)?

It's simple. It works. Use it. As Kevin Low points out though, you will need to go through and fix up the bits where you use Core Foundation objects. That will just require a healthy lashing of __bridge or __bridge_transfer though.

2) Does it help me in reducing my apps memory foot-print, memory leaks etc (somehow ?)

Nope, not really. OK, sort of. It will help reduce memory leaks where you have coded incorrectly previously. It won't reduce memory footprint.

3) Does it has much testing impact on my apps ?

None whatsoever.

4) What are non-obvious advantages?

The future. There'll be more to come on the bonus that the compiler taking an intricate knowledge of how objects are reference counted gives. For example ARC provides the lovely objc_retainAutoreleasedReturnValue optimisation already, which is very nice.

5) Any Disadvantage os moving to it?

None whatsoever.

Please take my word for it and start using ARC. There's no reason (IMO) not to, thus the advantages definitely out-weigh the disadvantages!

For an in-depth look at how ARC works to perhaps help convince you that it's good, please take a look at my blog posts entitled "A look under ARC's hood" - here, here, here & here.

Vincent Gable
  • 3,455
  • 23
  • 26
mattjgalloway
  • 34,792
  • 12
  • 100
  • 110
  • 1
    ARC will definitely reduce high tide memory footprint, since some things will be disposed of sooner — even if the application handled memory correctly before. – Steven Fisher Mar 26 '12 at 17:19
  • 2
    No it won't. If you think it will, please provide me with an example demonstrating this. – mattjgalloway Mar 26 '12 at 17:20
  • 6
    Read the LLVM docs on the subject (section 3.2.3). It can short circuit the autorelease pool for function results, resulting in the memory being freed immediately rather than on the next run loop. If you have a loop with several such allocations, you've now reduced your high tide usage. – Steven Fisher Mar 26 '12 at 17:31
  • 1
    OK, fair enough :-). I did talk about that in my answer though - the optimisation is `objc_retainAutoreleasedReturnValue`. Although, unless you're calling a method that returns something autoreleased inside an inner loop, then you're not really going to see much difference. And also, that object might still be autoreleased later for other reasons hence making no difference. – mattjgalloway Mar 26 '12 at 17:38
  • 3
    Loops working with strings are not uncommon. I'll certainly grant that you could have had an `@autoreleasepool{}` before, but you'd have to realize it was a problem first. :) At any rate, ARC is not going to **negatively** affect your memory usage, and **may** help it. – Steven Fisher Mar 26 '12 at 17:40
18

Here's what you really need to know about ARC:

The compiler understands Objective-C and Cocoa better than you. I don't mean this as an insult; it understands it better than me. I think you could safely say it understands the rules better than all but maybe a dozen people worldwide. And it knows tricks to use them to a degree that you and I can't repeat, even if we understood as well as it does.

The rest is just details:

  • You will write a lot less boring code. Code so boring it's easy to make mistakes.
  • As a blended compile time and run time process, it has access to tricks that you don't.
    • It will a better a job of writing memory management code than you can, even if you write the theoretical perfect memory management code.
    • It will reduce "high tide" memory usage (somewhat) without any effort on your part.
    • With zeroing weak references, it's much easier to avoid crashes caused by dangling pointers.
  • If you are starting a new application, stop thinking about it and just use it.
  • If you have an existing application:
    • You will need to re-test it. You need to make sure you have no circular references.
    • If you have an existing application that targets iOS before iOS 5, zeroing weak references are not supported. You should seriously consider requiring iOS 5.
    • If you have an existing application that targets iOS before iOS 4, you can't use it at all. What are you thinking, supporting crap that old?!?
  • In the last version of Xcode, it was not entirely bug free. It probably still isn't. But it's still worth using.
Steven Fisher
  • 44,462
  • 20
  • 138
  • 192
5

  1. If you're using Core Foundation or non-Objective-C code, then it's not as simple as you will have to manually go through your code and make sure all the casts between Objective-C and Core Foundation are bridged (if you have any casts). You'll also still have to manage memory for non-Objective-C code.

  2. It's supposed to essentially take care of all memory leaks for you, since it automates the retain, release, copy, etc. So far, I've never had an Objective-C leak since switching to ARC.

  3. No. Building might take a tad bit longer since it has to go through all your code and insert all the retain and release code.

  4. Not sure if there are any. In the end, all ARC is, is an automator.

  5. You will have to learn about bridged casts as well as you cannot build for anything lower than iOS 4.

In the end, it's definitely worth it. I was skeptical at first, but after watching the WWDC video where they explain how it works, I liked it more and more.

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
Kevin Low
  • 2,672
  • 16
  • 17
  • A small additional advantage is that ARC code does optimizations you can't. That means that (counter-intuitively) ARC code ought to perform better. And for #3, you might want to say that if this is an existing app, it's certainly going to have to be re-tested after conversion. – Steven Fisher Mar 26 '12 at 17:17
  • OOI, why do you think it's counter-intuitive that ARC code can perform better? – mattjgalloway Mar 26 '12 at 17:18
  • Actually, I don't. But "How can it perform better? It's doing extra work!" is an argument I've heard a few times. – Steven Fisher Mar 26 '12 at 17:29
  • But it's *not* doing extra work. It'll highly likely be doing less work, or at least it'll be doing the same. ARC is not garbage collection. Reference counting is still going on. – mattjgalloway Mar 26 '12 at 17:31
  • Oh yes, you're right. I figured that would have been a given; to test your app after a massive conversion =P. – Kevin Low Mar 26 '12 at 17:32
  • I know, Matt. These are the arguments I hear all the time. :) To be fair, in some cases ARC *does* do extra retains/releases, mostly because it understands some situations that the programmer thought were safe aren't. But with retain/release so much faster… I guess these are details people don't need to know. It's smarter. It's better. It's faster. It's less code. It understands Objective-C and Cocoa better than all but maybe a dozen programmers in the world. Stop thinking about it and use it. :) – Steven Fisher Mar 26 '12 at 17:44
3

Have you read Apple's documentation on ARC? It answers a lot of the questions you're asking.

Based on my experience, here's what I think:

  1. Yes, it's simple. You definitely need to test your app after converting, though.
  2. It can help reduce your app's memory usage and leaks, but it's not guaranteed to do that.
  3. Yes. You'll want to test after converting to ARC.
  4. You don't have to waste as much time thinking about and tracking down leaks. You can spend more time and energy on your app's actual code, rather than worrying about retain/release. Even if retain/release code is natural and easy for you, you're not infallible and you'll occasionally forget to release something. ARC doesn't forget.
  5. If you're supporting iOS 4, you'll have to handle weak references, as ARC doesn't support those in iOS 4.
Josh Brown
  • 52,385
  • 10
  • 54
  • 80
1

I discovered: ARC makes your code A LOT faster. In Apples WWDC video they say, that a couple of CPU cycles are saved for each NSObject's retain and release methods. This is because there is no need to check it on runtime anymore (It is outsourced to the compiler now). It's about 6 CPU cycles for each retain. If you use a loop which creates a lot of objects, then you can really feel the difference.

ARC not only makes the code faster, but YOU write less code, which accelerates your development process dramatically. And last but not least you must not search for memoryleaks by about 90% of your code. If you don't use a lot of low-level stuff, which must use "__bridge casts", you are COMPLETELY out of memory leaks.

Conclusion: If you can do it, DO IT!

JackPearse
  • 2,922
  • 23
  • 31
1

3) You should re-test your apps, but in my experience it will pretty much just work. Look at all the compiler warnings very carefully though!!!

4) Non obvious advantages: it's just really faster to code when you do not have to think about memory management. Perhaps that is obvious but the amount it helps still surprised me.

5) Disadvantages: Really the only disadvantage is having to turn off ARC for some third party libraries.

ARC has been so useful I simply will not code without it any longer. There's no reason to have to deal with all of that any more and it works well enough in practice.

Kendall Helmstetter Gelner
  • 74,769
  • 26
  • 128
  • 150
1

Watch the WWDC video on ARC: https://developer.apple.com/videos/wwdc/2011/?id=323

Apple's official stance in that video is that all apps that can use ARC should use ARC. The video goes into why, and is an excellent overview of the technology, so I'm not going to repeat it all here.

jsd
  • 7,673
  • 5
  • 27
  • 47