On Jul 10, 2008, at 9:50 , Michael Ash wrote:
On Thu, Jul 10, 2008 at 12:17 PM, Marcel Weiher <[EMAIL PROTECTED]
> wrote:
[hash tables not generally used + internal refcounts]
Atomic updates are still a pretty big hit on a multiprocessor system
(all of them, these days),
Yes, they're definitely not free.
and implementing your own is a fair amount
of work that you simply don't have to do in a GC environment.
Not really, no.
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.
There are several ways to share the implementation:
1. Do nothing, CF and Foundation already do it for most of their objects
(and they share their implementation...probably unreasonably...)
2. Implement a common superclass
3. Implement a function, inline function or macro that takes a pointer
to the refcount ivar.
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.
It's not a replacement, because the overheads are not
identical, neither in time nor in location.
Why do you say that? The write barrier code gets called when when you
store an object into an instance variable, same as for a retain. They
are actually at pretty much precisely the same time and location.
I am guessing you are referring to the scanning overhead, about which
you are right: it happens at a different time and in a different
place, and in addition to the checks.
For example, in the very
common scenario of creating temporary objects which never leave the
stack, a write barrier is never generated.
Yes, just like objects don't get retained when they are stored in
local variables, that happens when you store them into instance
variables.
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.
Taking into account the programming style a language supports is about
as far from a micro-optimization as you can get. It is an
architectural concern that informs how you structure your system,
changing it after-the-fact often turns out to be impossible. At least
that's been my experience over the last 20 years or so, YMMV.
I'd rather look at how GC compares to refcounting in typical usage,
not this kind of carefully optimized usage that rarely happens.
You might have heard about the 80/20 rule, which is actually more a
90/10 or 95/05 rule: most of the execution time is spent in a very
small portion of your code. Being able to go in and *really* optimize
those hotspots actually gives you the most bang for the buck. The
"typical usage", meaning the bulk of the program, generally does not
matter.
This is one of those areas where Objective-C really, really excels:
the ability to combine very high-level, very abstracted code with
small bits of highly optimized code to get an optimum balance of
expressiveness and performance.
...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.
The latter part is only true iff your apps do not need to responsive.
I prefer apps that are. The first part is where that 95/5 rule comes
in and being able to tune those hotspots really comes in handy.
Cheers,
Marcel
_______________________________________________
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]
