On Apr 26, 2014, at 4:29 AM, Dave <d...@looktowindward.com> wrote: > Yes, because of autorelase! Take autorelase out of the equation and it doen’t > use 150MB!
Autorelease is a great example of There Ain't No Such Thing As A Free Lunch. (TANSTAAFL) Before you gripe any further about it, I invite you to build a ref-counted object model from scratch that doesn’t use something like autorelease. (It’s not hard, really, in fact it should take you an hour or less. All you need is a base class with a retainCount ivar, a retain method that increments it, a release method that decrements it and calls dealloc when it hits zero. I suggest doing it in pure C or in C++, to avoid confusion with the existing Obj-C methods.) Then try to use it in a real program. You’ll quickly run into the very annoying problem of how to return a refcounted object from a method, when the called method doesn’t keep a reference to the object. This is what autorelease solves. Without it, you have to use a coding convention where the caller is responsible for releasing the returned reference when it’s done with it. You either have to make _all_ returns work that way (which will add a ton of unnecessary retains to the callers when they return an object they do own), or indicate in the method name somehow whether or not the caller is responsible for the reference (e.g. “getFoo” vs. “getRetainedFoo”.) Then you run into the really awful problem of what happens when you override a method that has one behavior but your subclass method needs to have the opposite, only it can’t because it has to have the same name and contract as the superclass. D’ohhh! Welcome to my life when I worked on OpenDoc, an old Apple framework that used retain/release. It was a bloody mess. Autorelease is a fairly brilliant fix for this. Yes, autorelease is not free; you do have to think about its existence sometimes to avoid pathological cases like long loops that accumulate autoreleased references. But the only reasonable alternative is garbage collection, and as we all know, that’s far from free too — but you pay in runtime memory footprint and performance. Apple’s decided that having the programmer pay a slight cost to babysit autorelease pools is preferable to making the user pay the price of slow and memory-bloated apps. —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
