Re: Class gets EXC_BAD_ACCESS only as NSOperation
Re: Class gets EXC_BAD_ACCESS only as NSOperation
- Subject: Re: Class gets EXC_BAD_ACCESS only as NSOperation
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 24 Mar 2009 12:58:05 -0700
On Mar 24, 2009, at 11:45 AM, Alexander Spohr wrote:
how about NSZoneMalloc() / NSZoneCalloc()?
Wouldn’t it be nice to create a Zone and just dump if if you’re done
with all those data?
Zones are generally dangerous.
To gain any benefit, you need to have a usage pattern that causes lots
of small allocations with few deallocations. And when you dump a
zone, you have to be absolutely positively sure that there are no
references to any of the data within the zone. If there is, you just
created a dangling reference. Of course, if your zone is full of
lots of small allocations, it is much more likely that you might have
a dangling reference into the zone.
For Objective-C, dumping a zone is even more catastrophically error
prone. When you dump a zone, none of the objects will receive any
kind of notification. Thus, no tear down is possible without doing
something manually.
Of course, under GC, you can't allocate objects from said zone, so the
point is somewhat moot.
In the OP's case, the buffer's are relatively large -- more than a
page in size -- and it sounds like they are relatively infrequently
free()d / malloc()ed again. Thus, a zone won't buy much. The OP
will quite likely be better off -- will achieve better memory
performance -- by allocating as needed and freeing when done.
If memory performance proves to be a real problem, something that can
only be verified through measurement, then there are a number of
alternatives to investigate.
b.bum_______________________________________________
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