Re: garbage collection and NSConnection
Re: garbage collection and NSConnection
- Subject: Re: garbage collection and NSConnection
- From: "Michael Ash" <email@hidden>
- Date: Thu, 10 Jul 2008 12:50:53 -0400
On Thu, Jul 10, 2008 at 12:17 PM, Marcel Weiher <email@hidden> wrote:
> Some minor factual corrections:
>
>
> On Jul 2, 2008, at 18:33 , Michael Ash wrote:
>
>> In Cocoa you do lots of retaining and releasing. These operations
>> aren't free. They involve a lookup into a global hash table and some
>> sort of atomic increment/decrement operation.
>
> The hash table is only used by NSObject subclasses that do not implement
> their own inline reference count. Most Foundation objects do implement such
> an inline reference count, so there are no hash lookups involved, just the
> atomic increment/decrement. I would strongly recommend that you implement
> an inline reference count for your own objects if they undergo frequent
> ownership changes.
Atomic updates are still a pretty big hit on a multiprocessor system
(all of them, these days), and implementing your own is a fair amount
of work that you simply don't have to do in a GC environment.
Especially since you can't reasonably implement it once and share the
implementation, you'll have to manually insert the implementation into
your classes individually.
>> They're pretty fast, but
>> there's certainly some cost there. Garbage collection lets you
>> eliminate all of this code, so you get a speed bonus there.
>
> GC does not eliminate this overhead, it replaces it with the overhead of the
> write-barrier functions that are called when you do an assignment. These
> calls are generated automatically by the compiler, so you don't see them in
> your code, but they are still function calls. This is in addition to the
> scanning overhead.
No, it *does* eliminate this overhead, and it has this *other*
overhead. It's not a replacement, because the overheads are not
identical, neither in time nor in location. For example, in the very
common scenario of creating temporary objects which never leave the
stack, a write barrier is never generated.
>> The question of memory usage is far from a given, especially in Cocoa
>> where you do lots of autoreleasing. The pervasive use of autorelease
>> essentially means that objects don't go away until you go back to the
>> event loop.
>
> They generally go away whenever you want them to go away. The top of the
> event loop is a good default, but it is just that: a convenient default.
>
>> This can result in large spikes in memory usage during
>> event processing.
>
> If you see such spikes, simply add autorelease pools to your processing.
Yet more work that you don't have to do in a GC system. And
autorelease pools, while quite cheap, are not free.
> Also: don't gratuitously create and/or autorelease objects if you don't
> have to. Objective-C object-creation is pretty heavy-weight compared to
> other OO languages, regardless of wether you are using garbage collection or
> reference counting, so programming-styles that do a lot of object-creation
> will suffer, performance-wise.
You can bend your programming style to micro-optimize the language's
speed if you want, but that's not the kind of thing I prefer to do.
I'd rather look at how GC compares to refcounting in typical usage,
not this kind of carefully optimized usage that rarely happens.
>> Cocoa's GC also has another interesting advantage: most of the work is
>> done on a background thread. This means that on any multi-core machine
>> (which is any Mac sold in the past couple of years) that isn't already
>> loaded at 100%, this bulk of the GC work essentially comes "for free".
>
> ...as does doing the work during the top of the event loop when the machine
> is waiting for user input.
This doesn't work when you're compute bound, which is of course the
only time that performance actually matters anyway.
> Of course "free" is actually not free (a) in
> terms of power consumption and (b) in terms of memory bandwidth, which is a
> shared resource between the cores and frequently the bottleneck these days
> and (c) if you have other work for that core.
That would be why I put it into quotes. The point being that while
it's not really free, it takes no additional wall-clock time in the
common case.
Mike
_______________________________________________
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