Re: Turning off the garbage collector for Xcode 3.0
Re: Turning off the garbage collector for Xcode 3.0
- Subject: Re: Turning off the garbage collector for Xcode 3.0
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 05 Aug 2008 20:18:22 -0700
On Aug 5, 2008, at 7:36 PM, Steve Checkoway wrote:
On Aug 1, 2008, at 8:38 PM, Clark Cox wrote:
The work done by the garbage collector has to be done one way or
another. If not running under GC, that same work would be spread
throughout your program in the retain/release calls, as well as the
autorelease pool tracking.
This is not true. The garbage collector must figure out which
objects can be collected. This is not work that would have to be
done without a garbage collector.
In non-GC, explicit retain/autorelease/release calls have to be made
that are not needed in GC. Only the actual returning of the memory
to the system is the same both with and without GC.
That said, it sounds like GC is not the OP's issue at all.
Actually, the differences between are significantly more complex. The
collector is, specifically, conservative, generational, and non-
blocking. That is, it runs on a background thread, doesn't move your
cheese, and doesn't always scan everything -- is not always active.
On a multi-core system, it means that the work normally related to
retain/release/autorelease doesn't have to occur on the same core as
the thread upon which those calls were made in the non-GC case. It
allows for memory management work to be moved off of the thread.
It also makes transfer of ownership between threads much easier -- -
autorelease can't help here and, thus, non-GC requires careful retain/
release handshakes between threads, which can be greatly complicated
by various design patterns. More fundamentally, a simple atomic
assignment is enough to express ownership -- thus, under GC, these two
properties will have a very similar performance profile:
@property(retain, nonatomic) NSString *a;
@property(retain) NSString *b;
But under non-GC, the second version is a couple of orders of
magnitude slower due to various locks and exception handling
gymnastics that must be performed.
Similarly, GC can potentially reap memory much sooner than an
autorelease pool. Whereas an autorelease pool may keep an object
around until a run loop cycles, possibly blocking before that happens,
GC can deallocate the object as soon as it is no longer accessible
within the application's object graph.
GC also enabled certain design patterns that are inconvenient or
costly to implement in non-GC. In particular, the zeroing weak
references can be brilliant within notification engines, inspectors,
and the like; cheap, safe, and automatic.
As well, offloading memory management to the system gives Apple the
opportunity to engineer various optimizations that simply aren't
possible under non-GC. But I can't talk about that.
So, no, simply stating that "GC does more work" or "non-GC is
faster". The reality is much more complex; there are advantages to
both schemes, but GC is far more likely to reap benefits of multi-core
systems and Apple's optimizations therein than non-GC.
b.bum
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden