What is this new fangled ARC???

Discussion in 'iOS Programming' started by chrono1081, Oct 15, 2011.

  1. chrono1081 macrumors 604

    chrono1081

    Joined:
    Jan 26, 2008
    Location:
    Isla Nublar
    #1
    Hi guys,

    I've been working on my iOS programming since I am now out of school (well, I will be next week :D ) and I've noticed with XCode 4.2 it doesn't let me release objects in my programs anymore or create an autorelease pool and brings up a message about ARC (Automatic Reference Counting I'm guessing?)

    Well, being a learner I don't want this feature since I want to manually manage my memory, but I am finding all kinds of crazy solutions on how to turn it off in XCode 4.2. Is there a simple way to do this that won't screw me up? I didn't see an option anywhere.
     
  2. MorphingDragon macrumors 603

    MorphingDragon

    Joined:
    Mar 27, 2009
    Location:
    The World Inbetween
    #2
    ARC is an extension to Clang's static analysis, so in theory it is superior to standard Garbage Collection as there isn't or there isn't as much as a runtime hit.

    ARC is part of LLVM and is enabled during compile time. To disable it you would need to change the compile command XCode uses when it compiles projects.

    I cant remember where so have fun with finding that.
     
  3. jiminaus, Oct 15, 2011
    Last edited: Oct 15, 2011

    jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #3
    You want to read the Transitioning to ARC Release Notes.

    The Automatice Reference Counting section of the Xcode New Features User Guide tell you about the new Xcode command for converting a project to ARC.

    You might want to read the Storyboarding section of that same guide. Storyboarding is another new feature of XCode 4.2 which could make your job easier.


    There is no advantage to not using ARC, especially because you're a beginner. The only time you wouldn't want to you ARC is if you want to support iOS 3 or you have weak references and want to support iOS 4.


    If you really want to do this, go in the Build Settings of your project. Under the Apple LLVM compiler 3.0 - Language group, you should find the Obejctive-C Automatic Reference Counting option which you can change to No.
     
  4. MorphingDragon macrumors 603

    MorphingDragon

    Joined:
    Mar 27, 2009
    Location:
    The World Inbetween
    #4
    Chrono1081 main area of specialization is games. In serious game programming, knowing when objects appear and disappear is a boone for optimizations.

    Hence why I dislike XNA.
     
  5. jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #5
    Ah, then forget about storyboarding as well then, perhaps.
     
  6. jnoxx macrumors 65816

    jnoxx

    Joined:
    Dec 29, 2010
    Location:
    Aartselaar // Antwerp // Belgium
    #6
    Manual retaining/releasing your objects in WHATEVER project you are coding I still find it superior to anything that will autorelease it for me.
    Why? because optimisations, Singletons, Improving your knowledge of MVC Patterns etc. Just so you perfectly know what you are coding, some will say, omg, ARC FOREVAR. But seriously, I know memory management sux, but I recommand it for every programmer since it will HELP you actually UNDERSTAND what you are doing.

    Enough ranting, it's a personal issue i guess.
     
  7. MorphingDragon macrumors 603

    MorphingDragon

    Joined:
    Mar 27, 2009
    Location:
    The World Inbetween
    #7
    ARC is fine compared to Garbage Collection which is horrid.

    512MB used for diarry app, problem?
     
  8. admanimal, Oct 15, 2011
    Last edited: Oct 15, 2011

    admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #8
    It doesn't hurt to understand manual memory management, but once you do there is no reason not to use ARC. The time savings in writing/maintaining/debugging your code will far outweigh whatever very meager (and probably nonexistent) performance gain you'll get by not doing it. In fact the @autoreleasepool directive in ARC is 6 times faster than using an NSAutoreleasePool, and all of the other memory management functions that ARC will use (retain/release/objc_msgSend) have been significantly optimized as well. I also don't know what it has to do with someone's ability to use MVC or any other pattern.
     
  9. jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #9
    Interestingly what used to be called the Memory Management Programming Guide, which talks about retain and release, is now called the Advanced Memory Management Guide.
     
  10. Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #10
    Garbage collection has never been available for iOS, for obvious reasons. The CPU time and memory cost of GC are simply too high for mobile devices. ARC bridges that gap nicely: takes the memory management out of the programmers' hands while not costing the system any extra loading (in fact, replacing -release messages with a shortcut that makes it even more efficient). This is the convergence of Mac OS and iOS.

    I would not be surprised if GC were deprecated very soon, perhaps even causing applications that rely on it to become incompatible around the time of 10.8.x.
     
  11. amorya macrumors 6502

    Joined:
    Jun 17, 2007
    #11
    ARC is entirely predictable about when things get deallocated. It's not like garbage collection, where things will get deallocated next time the collector runs — with ARC, as soon as there are no more strong references to an object, it's gone. There and then, immediately, as if you had written [object release] yourself on the next line.

    (That's a simplification that doesn't mention autoreleasing and other such things, but it's all still predictable.)

    Hence, there's no point doing manual memory management for the sake of optimisation. If you want to optimise, you can still do that with ARC (by checking where you assign nil to your strong references, for example). Also, with ARC, you get a whole bunch of speedup for free, because the release calls ARC makes behind the scenes are faster than an objective-C method call.

    With old-fashioned garbage collection, I agree with you that often it's better to optimise things yourself. But given that ARC isn't non-deterministic in the same way, I reckon you'd have to be doing something crazy weird in order to benefit from manual memory management.
     
  12. ArtOfWarfare macrumors 604

    ArtOfWarfare

    Joined:
    Nov 26, 2007
    #12
    Are performance tools for checking for leaks and checking memory usage and such a thing of the past, then?

    Hurrah if it's so!

    Will ARC also prevent zombies?
     
  13. jiminaus, Oct 18, 2011
    Last edited: Oct 18, 2011

    jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #13
    No, because ARC doesn't prevent retain cycles from leaking. For example, if object A has a strong reference to object B, and object B has a strong reference to object A, but there are no other strong references to either object A or object B, those objects will never be dealloc'ed.


    Yes if you only store object pointers in strong or week variables/properties.

    But if you do something like store an object pointer in an __unsafe_unretained variable or property, or something like a void* variable using just a __bridge cast, then you still have the risk of zombies.

    Note that under ARC, a property with the assign attribute is equivalent to __unsafe__unretained.
     
  14. Sykte macrumors regular

    Joined:
    Aug 26, 2010
    #14
    Just to clarify ARC is not Garbage Collection and ARC does not have an affect on runtime.

    You can turn ARC off per file or per project very easily by setting the following -fno-objc-arc.
     
  15. MorphingDragon macrumors 603

    MorphingDragon

    Joined:
    Mar 27, 2009
    Location:
    The World Inbetween
    #15
    I never claimed it was.


    Useful information. Adding to to my cheatsheet.
     
  16. Sydde macrumors 68020

    Sydde

    Joined:
    Aug 17, 2009
    #16
    From what I have been reading, the ARC mechanism does have an affect on runtime, and in some cases, it can be nontrivial. The hidden retains and releases short-circuit the message passing system, so the runtime effect would be a net positive (performance improvement). In heavy use code that is thick with retains and releases, this could theoretically provide observable speed gains. Or, in the case of a large object map thick with strong references, releasing a top end object could recurse through the implicit -deallocs more quickly.

    ARC should be the opposite of a runtime hit.
    Would this mean that a project could mix ARC with manual reference counting? Would that work? Would it make sense?
     
  17. jiminaus macrumors 65816

    jiminaus

    Joined:
    Dec 16, 2010
    Location:
    Sydney
    #17
    I think it would be just a bridge cast back and forth between ARC and non-ARC code.
     
  18. admanimal macrumors 68040

    Joined:
    Apr 22, 2005
    #18
    Yes, just as it says, you can turn off ARC for individual files in a project. So some of your classes can use ARC, and others don't have to. There's not really any magic here; the compiler just won't insert any memory management functions in the non-ARC code like it would for the ARC-enabled code.
     
  19. Sykte macrumors regular

    Joined:
    Aug 26, 2010
    #19
    Think of ARC in this way; it's a fancy find and insert that follows the memory management rules. Considering memory management is a strict but simple rule set, its only a matter of adding release\autorelease\retain messages to code that requires it. This is done by the compiler so memory management messages are being inserted at compile time not runtime.

    So yes, you may turn ARC on/off per file.

    Apple overhauled NSObject and optimized retain/release for performance. This is where and why you will see a performance increase with retain/release.

    No, how do you figure that. ARC sends the same message of "release" as a developer would send. Remember you can still force destroy and setup autorelease pools, so how would you see a difference in performance. If you are handling memory poorly without ARC then yes you will see a performance increase.
     
  20. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #20
    The major advantage of not using ARC is that only a microscopic fraction of the books, web tutorials, and even Apple's sample code shows how to use it.

    Until the more popular iOS programming books are revised, I would leave ARC use to more expert programmers capable of figuring it out from Apple's terse documentation. This will have the major advantage that even if a new programmer eventually never uses manual memory management again after the major tutorials are revised, they will better understand what's going on the their app's memory footprint, and be in a far better position to debug things if they do accidentally code a retain loop or something.
     
  21. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #21
    @firewood, while I would tend to agree with you Apple doesn't. 4.2 has made changes that encourage you to use ARC. All the templates have no dealloc method. When you add outlets by dragging from a nib to a header file it doesn't add the release anymore to the code. I haven't taken the time yet to come up to speed on ARC but it seems clear that Apple wants developers to do it ASAP.
     

Share This Page