Re: ARC vs Manual Reference Counting
Re: ARC vs Manual Reference Counting
- Subject: Re: ARC vs Manual Reference Counting
- From: Dave <email@hidden>
- Date: Tue, 10 Sep 2013 20:33:06 +0100
Hi,
You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). On 80386's and 486's this made an incredible difference. Leaks could be detected at the point in which the leak occurred (e.g when all references to the object were gone) and either release it or throw an exception.
I think the overhead was an 8 bytes descriptor which was help in a private fast store SRAM for those in the know!) for each object allocated. In those days we were limited by the cost of the capacity of the devices. If Apple were to implement something like this I think there would be a massive increase in performance and reliability
Cheers
Dave
On 9 Sep 2013, at 23:45, Patrick Cusack <email@hidden> wrote:
> I appreciate everyone's replies. It was a question asked in complete humility. I agree that computers can do analysis much better than humans and that the less code you write, the less you have to debug, so ARC makes a lot of sense. My question really stemmed from Apple's WWDC lecture which appeared to justify the switch on the flimsiest of grounds, ie no longer having to be confused by [NSString stringWithFormat:] vs [NSString initWithString:] which is a pretty easy memory management rule.
>
> As my main application is 32 bit (on account of the Quicktime API), I haven't had much exposure to ARC yet. So I will be upgrading with Mavericks to ARC and AVFoundation.
>
> Thanks for all of the comments.
>
> Patrick
>
> On Sep 9, 2013, at 7:29 AM, Alex Zavatone wrote:
>
>>
>> On Sep 9, 2013, at 3:58 AM, Tom Davie wrote:
>>
>>>
>>> On 9 Sep 2013, at 09:44, Kyle Sluder <email@hidden> wrote:
>>>
>>>> Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer.
>>>>
>>>> --Kyle Sluder
>>>>
>>>> On Sep 8, 2013, at 11:18 PM, Alex Kac <email@hidden> wrote:
>>>>
>>>>> Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance.
>>
>> I think the big point is that if the compiler can figure out what is no longer needed and can be released, and the compiler can do this (at a reasonable cost to performance), then this is a no brainer.
>>
>> I'm sure there are special cases where you would want to do your own memory management. And in this case, you can always flag the class files to turn off ARC and manage memory yourself.
>>
>> Simply put, not having to worry about this gives more brain stack space to fill up with all the other parts of Cocoa and Objective-C that we need to keep track of and saves valuable developer time since it's now rare to have to deal with manual memory management mistakes.
>>
>> Cheers,
>> - Alex Zavatone
>>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden