On Thu, Jul 10, 2008 at 12:17 PM, Marcel Weiher <[EMAIL PROTECTED]> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
