John Engelhart wrote:
> On Sat, Jan 17, 2009 at 7:44 PM, Scott Ribe <em...@hidden> 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:
That is one good example, but there is *much* more to it.
> 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:
> [code]
> 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.
An additional problem is that it does not scale well. Programs mature,
objects are used beyond their initial intent, programmers come and go
and that source becomes a nightmare to maintain. Getting back to good
OO style, why take the messaging overhead (how often do your
subclasses rewrite getters/setters?), the poor style, or the program
that is extremely difficult to maintain -- when you generally won't
need any of that?
Why deny free optimizations (provided by the compiler) and risk poor
design/maintenance headaches?
> 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.
But who *wants* to maintain code with inconsistent ivar accessing?
That misses the point and power of oo design, as well as the
simplicity of it (where applicable). Default visibility was decided,
for good reason.
> 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.)
Nor is it fair to assume that somebody would want to make their
program more complex to maintain than necessary by doing so,
especially when these are often gratis in another language. It's all
coming back to the right tool for the job at hand. I don't mean to
sound like I believe one language is superior, they each have their
strengths (and weaknesses). Objective C is great (depending on how it
is used). C++ is great (depending on how it is used).
Justin
_______________________________________________
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
