From: "John H. Robinson, IV" <[EMAIL PROTECTED]>
Gabriel Sechan wrote:
>
>
> Here's the problem with the idea of optimization at the end. CHanging
the
> code later is more expensive than changing it early.
Assuming I am correct, but optimisation includes things like changing
i = i + 2;
into
i += 2;
while changing
f(int i);
into
f(char *i);
would not.
If you think that changing an interface is a valid optimisation
technique, we can end this discussion now, as we have vastly different
ideas as to what optimisation is.
Both are optimizations (although I'd throw out any compiler that didn't
create the same code for your first example). Or perhaps better put, both
are performance issues (I'm sure you agree that getting the right interface
effects performance). Do you prefer that term?
> Its cheaper to fix a bug in design than in coding, its cheaper to fix
> it in coding than in testing.
Yep. If you add ``It is cheaper to fix code before optimisation'' then
you will get what the original quote said.
Depends on the level of optimization. If you're dropping into assembly or
rewriting an entire portion based on implementation details of another part
of the code, its probably a bad idea. Taking a minute to think about what
you're doing and realising that calling function Foo can be done outside of
a loop is a good idea.
> By the time you get to the end and try to optimize, you end up
> spending large amounts of time trying to figure out what to optimize,
> then an additional large amount of time doing so.
Your profiler will show you where the bottlenecks are. You won't know
that until it actually works. You can guess, but you will likely guess
wrong.
I disagree on likely guessing wrong. In my experience you generally guess
most of the top 10, but 1 or 2 surprises may come.
I'm not syaing drop to assembly, or throw out encapsulation or legibility to
improve performance. I'm saying think about performance when you code and
design. The modern "well Murphys law will save us" cult is going to be in
for a big surprise with processor speeds begining to flatline.
Gabe
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
