On Sat, Jan 17, 2009 at 7:44 PM, Scott Ribe <scott_r...@killerbytes.com> wrote:
>> TBH (and more to the point) I strongly suspect it's true of everyone
>> who's expressed an opinion in this thread that it's not so much about
>> the suitability of the language to optimizations, but more about the
>> skill set of the individual with regard to the language.
>
> Well, there is a degree of efficiency that can be had with C++ classes that
> simply cannot be had with Objective-C classes.
You keep mentioning this, but I don't recall seeing an example of this
'inefficiency' you keep referring to. If I were to take a guess at
it, I'd venture that it's along the lines of "accessing a variable of
a struct/class", or something along the lines of:
// C version
struct Example { int x, y; };
struct Example *ep;
int localX = ep->x;
ep->x = 1234;
// ObjC version
@interface Example { int x, y; }
- (int)x;
- (int)y;
- (void)setX:(int)newX;
- (void)setY:(int)newY;
@end
Example *eo;
int localX = [eo x];
[eo setX:1234];
In this particular example, the ObjC version is "less efficient" than
the "raw C" version. Each access to the 'x' class ivar has to take a
trip through the runtime message dispatcher. The C version translates
in to assembly that is really nothing more than loading/storing with a
pointer + the offset to the desired struct member (1-3 instructions,
give or take), which obviously and easily trumps the time it takes the
ObjC dynamic runtime version.
Of course, that's just one way to do it. The ObjC language doesn't
require that you write getters and setters to access an instances
ivars, that's just good OO programming style. But since you're
talking about "optimized performance" code then I think "knowing when
to bend the rules" is perfectly fair game, as long as you understand
the consequences. The ObjC example above can then be rewritten as:
@interface Example { @public int x, y; }
- (int)x;
- (int)y;
- (void)setX:(int)newX;
- (void)setY:(int)newY;
@end
Example *eo;
int localX = eo->x;
eo->x = 1234;
This translates exactly in to the same instructions as the "pure, raw
C" version. You obviously loose the flexibility of the ObjC OO
getter/setter way, but you're in control of that trade-off. This is a
completely acceptable "bending of the rules" when doing performance
optimization and the need for performance outweighs the loss of
functionality or extra complexity elsewhere to compensate for the
performance special case.
> It is a degree of efficiency
> that is not often required, but just as you can't "rewrite Cocoa in C++" as
> we've seen demanded by people who don't really understand Objective-C,
> there's levels of efficiency that in C++ can be combined with high-level
> abstractions, but in Objective-C would require raw C.
I'm not sure you appreciate the irony of having "people who don't
really understand Objective-C" and "but in Objective-C would require
raw C" in the same sentence. After all, Objective-C is nothing but
syntactic sugar for C- any ObjC statement can be rewritten in its
(usually far more verbose) C equivalent. When you get right down to
it, the core difference between C and Objective-C is the message
dispatcher, and its use is completely optional. If you decided to use
getter and setter methods to access a classes ivars, that was a design
choice on your part, not a requirement imposed by the language.
As a consequence of this, your statements that "ObjC is far less
efficient than C" are rather specious. The only reasonable way I can
think of that would lead you to this conclusion is that you're not
comparing apples to apples, i.e. you're using struct->var type
accesses in C, and getter/setter runtime dispatched methods in ObjC.
That's not a fair comparison, nor the way any sane person would code a
"performance optimized" version. (very?) Selective use of direct ivar
access and imp caching map to the equivalent of struct->member +
function calls in C, which effectively means that if you're not
getting the same (or very close to) performance from your "ObjC
performance benchmarks" as you are from the C version, you're doing
something wrong.
(note: Most of the above applies to the 32-bit runtime. I'm not
looking to start a 32/64-bit runtime religious war.)
_______________________________________________
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 arch...@mail-archive.com
