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: Bill Bumgarner <email@hidden>
- Date: Tue, 13 Nov 2007 16:12:28 -0800
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).
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.
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