Re: why use pow(x, 2)?
Re: why use pow(x, 2)?
- Subject: Re: why use pow(x, 2)?
- From: Jens Alfke <email@hidden>
- Date: Mon, 2 Nov 2009 15:39:12 -0800
On Nov 2, 2009, at 3:22 PM, Bob Smith wrote:
True, and not true, IMHO. It can be a pitfall to worry about
performance issues too early in a coding project. On the other
hand, by the time you know there is a performance problem it can
easily be too late for low-level code optimization, and you end up
with band-aid solutions like caching that impose unnecessary
modality on the UI.
That implies you either aren't allocating time for testing, or you've
got an unrealistic schedule.
And since compiler optimizations are never certain, it's best to
assume a function call is always more expensive than inline code.
This just isn't true any more, at least not the "always" part.
Actually I've spent the past week changing a whole bunch of heavily-
inlined code into non-inlined function calls. Why? Because CPU speed
is not generally the limiting factor in app performance anymore. The
bottlenecks are now RAM latency and disk speed, and the ways around
them are to keep code and data small. The smaller your code, the more
of it fits in the CPU's L1 and L2 instruction caches, and the less of
it there is to page in from disk on launch. The smaller your data, the
better the data caches work, and the less of your address space that
needs to be paged out to disk or back in.
And as people have pointed out, these days the time that's in shortest
supply is the programmers' time. It doesn't matter how fast your app
is if it never ships, or if you can't fix bugs because the code's too
obfuscated to read. My favorite example here is the WriteNow word
processor. It was ahead of the pack in the early days of the Mac, but
was left in the dust by the early '90s because it was written entirely
in 68000 assembly code -- this made it insanely small and fast, but
the team just couldn't add enough features to keep up with the other
word processors that showed up. (And by this I mean useful features,
like spell-check and multiple columns, not the feature-creep that
later ate Word.)
Learn to use macros effectively to enhance clarity and readibility.
Today people should be using inline functions for such things. Macros
have some very, very nasty pitfalls that can cause subtle errors and
make code nearly impossible to understand, and for the most part they
can be replaced with inline functions and constant declarations. (The
remaining uses for macros are for weird stuff you can't do in a
function, like pasting identifiers together.)
All you youngsters who never ran an app on a CPU at less than GHz
speeds, you ought to be forced to write code for an early-80's PC.
Now that was _real_ programming!
I remember those days (I even wrote some Z80 assembly code for CP/M
boxes) but coding today isn't anything like it was then, any more than
early PC coding was like mainframe FORTRAN. Intuition about
performance is a dangerous thing to rely on, unless you're an expert
at the problem domain.
—Jens_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden