Re: Memory limits under Garbage Collection, NSMutableData vs. malloc()
Re: Memory limits under Garbage Collection, NSMutableData vs. malloc()
- Subject: Re: Memory limits under Garbage Collection, NSMutableData vs. malloc()
- From: Rick Hoge <email@hidden>
- Date: Wed, 14 Nov 2007 11:11:06 -0500
On 13-Nov-07, at 7:12 PM, Bill Bumgarner wrote:
On Nov 13, 2007, at 2:30 PM, Rick Hoge wrote:
I'm not surprised there's some performance difference between
malloc() and NSMutableData's convenience constructor, but I'm a
little surprised at how much. Also I'm trying to figure out why GC
leads to a failure, when the same code run non-GC does not. I
guess it's quite possible that the collector may not know in
advance that it's about to be hit with a huge memory demand, so
perhaps it's let a lot of garbage accumulate at the time of my
constructor...
Obviously I can break the memory chunk up into smaller bits, or
just use malloc(). I'd just like to understand what's going on
under the hood a bit better to make appropriate choices in future
code.
Unless you are going to stuff the 700MB block of memory full of
pointers to objects controlled & scanned by the collector, just use
malloc. In a GC process, you have scanned and unscanned memory.
Quite literally, the collector scans every location eligible to
contain a pointer value looking for object refferences (with some
significant optimizations under the hood to avoid *actually*
scanning every address).
Is it always necessary to use scanned memory if I want to use GC? If
I know that the memory is just going to hold data values (not pointers
- e.g. pixel intensity values or something) can I use
NSAllocateCollectible(lotsOfPixels*3*sizeof(float),0); // The zero
means not to scan
I get the impression that the scan will allow the collector to be
aware of object references contained in the allocated memory - it's
not needed to collect the memory itself once it's no longer "reachable".
Thus, unless you are going to shove pointers to objects into that
700MB, you are far far better off using malloc(), which will leave
the memory as unscanned.
I don't mind using malloc/free pairs, but the prospect of
NSAllocateCollectible is interesting. My code has a number of
termination pathways (if some condition, return with a not-successful
code) and currently it's kind of messy as you need to provide free()
statements for any preceding malloc's (as good programming practice
has always dictated). If I could omit these free's the code would be
a lot cleaner (although the idea takes some getting used to).
Rick
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