Re: Optimisation [inlining] of message calls (was Re: Multiple problems caused by changing NSThreadsleepUntilDate interval)
Re: Optimisation [inlining] of message calls (was Re: Multiple problems caused by changing NSThreadsleepUntilDate interval)
- Subject: Re: Optimisation [inlining] of message calls (was Re: Multiple problems caused by changing NSThreadsleepUntilDate interval)
- From: Public Look <email@hidden>
- Date: Fri, 6 Feb 2004 16:18:16 -0500
On Feb 6, 2004, at 12:38 AM, Tregaskis, Wade wrote:
[snip]
This brings up a point which I've been thinking about recently (while
doing some C++ coding), which is that you would on the face of it not
be able to inline/reduce/similar message calls at all, no matter how
simple they are (e.g. standard getters/setters). Hypothetically if
you did inline them your compiled code would not be portable, since
other code would not be able to inline the methods at compile time and
would thus not have access to them.
But of course what you could do is inline methods in certain places
(e.g. the same source file) and leave the normal implementations in
place for external use.
Unfortunately, you might then have the problem that someone could use
a subclass that overrides one of those methods, and your existing code
wouldn't see that because of the inlining.
Nonetheless, if you weren't concerned with future compatability and
such things (i.e. it's an internal project), there is quite some
potential for optimisation - I'd love to be able to use this kind of
"static" ObjC for some work I've doing recently - rather than hacking
away at C++ trying to make a psuedo-ObjC, simply because the ObjC
overhead is prohibitive.
Does anyone know if there's any support for this in Apple's gcc, and
how to enable it? If not, is there any interest in this sort of thing
in future? I noticed Apple have added a few curious compiler options
recently, such as removing nil checks on messages, etc. They're
obviously aware of the problems with ObjC with regards to performance.
[snip]
In my experience, low level optimizations like inlining setters/getters
_usually_ have little or no value. I did work on a major application
that needed optimization in Objective-C setter/getter methods... more
at the end. There are also applications that are unsuited for using
Objective-C at all. Also more at the end.
The first rule of optimizing is to profile the code and find out where
all the CPU cycles are being spent. In most cases, the majority of CPU
time is spent in a small minority of code. In that case, find ways to
call that minority of code less often or make it execute faster when it
is called. Ignore the rest of the code because even it you cut its
execution time in half, it wouldn't result in perceptible improvement
in the application's performance. Profiling tools like gprof are
invaluable, and Apple provides "extra" tools as well.
Now, considering setters and getters specifically: It is a very strange
application that spends a large percentage of its time in setters and
getters. Most applications do a lot more than just copy values around,
and both the algorithms for processing data after it is set or obtained
and the CPU needed to display results completely dwarfs the time spent
actually setting or getting.
It is also unusual for Objective-C's message sending cost to have much
impact on overall application performance. The time spent within the
method implementation should normally dwarf any message cost to get to
the implementation.
There is a fantastic set of articles on low level Objective-C
optimization at
http://www.mulle-kybernetik.com/artikel/Optimization/opti.html.
There have been a huge number of postings on the topic of Objective-C
message dispatch speed:
http://groups.google.com/groups?as_q=optimizing Objective-
C message&safe=images&ie=ISO-8859-1&lr=&num=100&hl=en
"Cocoa Programming" includes a great section on optimizing.
Finally, messaging can be eliminated entirely by using IMPs, but that
does not provide inlining.
Here are the promised exceptions that prove the optimization rules:
One area in which I work is CPU emulators. These software systems
emulate CPUs at the micro-code level, and memory accesses needed for
emulated registers and other hardware features are too high a burden.
Adding function call overhead let alone messaging overhead would be
unthinkable when accessing these types of data. Any memory access at
all is avoided in favor of keeping emulated registers in host CPU
registers...
I worked on a simulation that basically modeled signals moving through
complex aircraft systems, data concentration units, multiple busses,
discrete wires, etc. In this simulation, the whole point of the job
was to copy data around. In other words, the setters and getters were
the core of the application. In order to avoid millions upon millions
of calls to setters/getters every second, we used Objective-C's
polymorphism and dynamism to obtain C pointers to the data being
"copied" and in most cases could just dereference the pointers to do
the work.
Dynamism was used to avoid coupling between objects. Messages would be
sent to anonymous objects and the objects would give each other
pointers to data. Data copying took place through the pointers until
one or more objects changed the system. When the system changed,
perhaps because a component failure was simulated or a new component
was dynamically added, notifications were sent to various objects, more
messages were sent to anonymous objects, new pointers were obtained,
and data would once again flow.
Notifications were used to tell subsystems when they needed to find or
change pointer values. In some cases, Objective-C IMPs were called
directly. The irony is that Objective-C's dynamism enabled/supported a
level of software sophistication that made data flow "optimization" a
realistic feature to add. In other words, humans would design a
complex data flow system. The simulation would then exercise the
system and using an expert/network analysis system consisting of
Objective-C classes, tell the humans where inefficiencies exited,
connections were missing, inadequate redundancy existed, and so on so
that the design could be changed. The changed design would then work
more efficiently in both the simulator and the aircraft.
_______________________________________________
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.