Re: Instance Variable access
Re: Instance Variable access
- Subject: Re: Instance Variable access
- From: "Tim Ramsey" <email@hidden>
- Date: Sat, 8 May 2004 08:27:30 -0500
>
Tim,
>
>
On 8.5.2004, at 2:54, Tim Ramsey wrote:
>
>
> the question is
>
> about how to avoid ObjC_msgSend in favor of a more direct route in the
>
> interest of speed
>
>
Others pointed out all those @defs, IMPs, et cetera.
>
>
I would like to emphasize that generally you *do not do that*.
I agree that "generally" you don't. Most user apps don't need it.
>
>
The smart way of writing good applications is first to design and
>
implement the thing exploiting the benefits of the *highest abstraction
>
API available*: not only objc_sends, but also HOM, KVC, with Web apps
>
those Direct... frameworks, whatever. That allows you to focus on the
>
algorithm, more often than not giving you a *huge* speed advantage --
>
it is not uncommon that, not being hindered by low-level
>
language/framework implementation details, you can find a way to turn a
>
"standard" polynomic solution into a linear one.
The smart way varies depending on the app. This is the smart way for many
apps. Not for the kind I write.
>
>
When done, you test and profile the application. More often than not
>
you'll find it is quick enough.
>
>
If not, profiling gives you bottlenecks. Then (and *only then*) it's
>
time to rewrite them into plain C or, in some cases (fractal computing,
>
video encoding...), perhaps even into the assembly language. Again:
>
presumed you used a hi-level approach, you saved a *considerable*
>
amount of time, which allows you now to hand-tune these things. Had you
>
used C++ or similar rot for the complete application, you would not
>
have the time now to play with Altivec to get the most of it in the one
>
bottleneck routine!
>
>
Always there will be exceptions to any rule of course, but in a vast,
>
vast majority of cases this approach gives you a result of some, say,
>
99.5% hi-level ObjC, 0.4% plain C and 0.1% assembly, which took just a
>
fraction of the effort you would need if you made the whole thing in,
>
say, C++, and the result will actually be *much faster*, for the plain
>
C/assembly parts are exactly where they are needed. It will also be a
>
better Mac OS X citizen, incidentally.
>
>
Remember: premature optimization is a bitch.
>
---
>
Ondra Hada
>
OCSoftware: email@hidden http://www.ocs.cz
>
private email@hidden http://www.ocs.cz/oc
>
Climbing on hobby-horse now: Refactoring etc. is nice but there is no
such thing as a one-size-fits-all design aproach. In this case, you
would have me throw away 40 years experience in optimization of numeric
methods SW for a cut and try approach. Even less stressing applications
can benefit from a certain amount of planning. Have you ever heard the
expression "Don't paint yourself into a corner?" Certain kinds of
optimization are premature in cetrain circumstances. That is all one can
say with certainty. You are simply pointing out those that are not
appropriate for user apps that only need trivial horsepower.
--
Tim
A man does not show his greatness by being at one extremity, but rather by
touching both at once. -Blaise Pascal, philosopher and mathematician
(1623-1662)
_______________________________________________
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.