Re: NSDictionary trouble
Re: NSDictionary trouble
- Subject: Re: NSDictionary trouble
- From: Ken Thomases <email@hidden>
- Date: Wed, 20 Jan 2010 00:47:06 -0600
On Jan 19, 2010, at 10:47 PM, Jeff Laing wrote:
> I'm assuming you are saying 'don't use the convenience methods because the autorelease pool won't empty quickly enough'. Certainly Ken said it, though he seemed to assume that there was only one pool, that people would not be creating their own in their known trouble-spots.
I didn't make that assumption. In fact, you quote me below referring to the "current pool". The word "current" is in there specifically because I kept the possibility of nested pools in mind.
I also didn't say "don't use ...". I was explaining Apple's recommendation, to the best of my understanding.
> Ken Thomases wrote:
>> The autorelease pool is convenient and in some cases necessary, but it
>> does come at some cost. It has some overhead in terms of time and
>> memory, plus it tends to increase the peak memory usage of your
>> program. (Over time, assuming you've got all your memory management
>> correct, a program's memory usage will come out the same, but
>> autoreleased objects accumulate over the lifetime of the current pool,
>> causing spiky memory usage.)
>
> But implicit in that seems to be that -[NSDictionary initWithObjectsAndKeys:] won't add to the auto-release pool and I don't see where that's a valid assumption (or at least a documented assumption).
I didn't make that assumption, either, and you're correct that doing so is unsupportable. However, the choice you make about which methods to invoke imposes restrictions on the frameworks.
If you use convenience constructors, you're essentially requiring the use of autoreleased objects. (Obligatory caveat: not all results from convenience constructors are necessarily autoreleased. This discussion is about those cases where they are.) If you use alloc+init, you at least allow the frameworks to minimize use of autoreleased objects. Whether or not the frameworks take the opportunity is beyond your control or caring. Given that it's Apple who are making the recommendation, one can hope the frameworks are coded to follow it.
I also pointed out that this is a matter of judgments about trade-offs and a recommendation (not a rule) particular to a highly-constrained environment. Personally, I don't develop for the iPhone and so the memory usage side of that tradeoff doesn't weigh as heavily for me.
Cheers,
Ken
_______________________________________________
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