Re: Instance Variable access
Re: Instance Variable access
- Subject: Re: Instance Variable access
- From: Andy Lee <email@hidden>
- Date: Sat, 8 May 2004 01:14:06 -0400
(Note: I haven't done C++ in many moons, so the following comments
might be based on an outdated understanding of the language...)
On May 7, 2004, at 3:05 PM, Jim Witte wrote:
Moreover, why are simple instance variable accesses even using
objc_msgSend (dynamic or otherwise) *at all*? Is there some reason
why ObjC object instance vars can't be accessed the same way they are
in compiled C++ - by direct offset access inside the object struct?
It sounds like you're talking about the ability of C++ compilers to
automatically inline small methods, such as methods that do nothing but
access an instance variable. IIRC, this only works if the method in
question is declared "final" (I *think* that's the keyword), and thus
the compiler can be assured you will never be able to invoke an
overridden version of the method. Objective-C has no "final" keyword
that would give the compiler the hint it needs to inline a method. The
equivalent in C++ would be if all methods were always virtual.
I suspect final methods have been asked for as a language feature in
Objective-C, and I can imagine some of the pros and cons that might be
debated (and some of the implementation issues). But for now, the fact
is that *all* methods in Objective-C can be overridden, and the
compiler has no way of knowing when it can safely inline a method call.
In other words, you cannot completely avoid Objective-C's messaging
overhead in a statement that uses message-sending syntax. You would
have to either use "myObject->myIvar" syntax or wrap that syntax in a
macro.
If this can be done, it (I think) would require that "simple
instance var access" methods be labeled/identified (by the compiler)
as such, so this optimization could take place.
This is essentially the effect of the "final" keyword in C++. If I
understand correctly, it's not so much a matter of the method being an
accessor as the method being small enough for the compiler to decide to
inline it, which accessors usually are.
What exactly does objc_msgSend do anyway? In C++, a method call is
just parameter (and object pointer) loads, and then a jump
Don't forget the cycles needed to calculate what that jump should be.
If you're calling a virtual method, work has to be done at runtime to
figure out which class's implementation of that method to use. Even
the object pointer is not a simple given: for a given object, the
memory address of "this" within a method may depend on whether the
method being executed belongs to the object's class or to a superclass
-- with the calculation being a little trickier if multiple inheritance
is used.
I'm not an expert on the Objective-C runtime, but I suspect
objc_msgSend() does something very similar, except it doesn't have to
do offsetting of the object pointer.
(of some kind - I don't know how PPC keeps track of the return
address). Cocoa can't be doing the same level of optimization,
because in Crash Reports, etc, you can see what methods are called by
objc_msgSend.
Are you talking about seeing method names in a stack trace? Can't you
do the same in C++, provided you haven't stripped method names from the
executable? If you do strip the executable, then *neither* language
can show you method names, AFAIK. In any case, this has nothing to do
with optimization for speed. The presence of debug symbols does not
slow the program down in either language.
the IMP pointer and dispatch through that. That should remove at
least 2 of the hoops the CPU has to jump through to get to your
method code.
IMP pointer? What's that?
It's short for "implementation"; it's a function pointer that points to
a particular class's implementation of a particular method.
Note that caching IMPs in your code does not achieve the same
performance gains as inlining would, because you still have a function
call. All you've saved is the work of calculating *which* function to
call.
One of the "concerns" (possibly unfounded) I've always had about
high-level object-based environments like Cocoa (and highly-layered
OS's like OSX) is a nagging feeling that if all the extra time for
message dispatch and other overhead
That's a reasonable concern, but the messaging overhead of Objective-C
is much closer to C++ than to, say, Java.
--Andy
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.