Re: Justifying Optimization

  MICHAEL DILLON <mike.dillon@lmco.com> wrote:


> I've been developing for twenty years, and ever since I've been
> allowed to have an opinion I've insisted that code ready for final
> testing and deployment be optimized. I'm currently responsible for my
> program's development strategy, and was recently blindsided by
> resistance to this approach. Developers are stating that optimized
> code produces errors and makes debugging more difficult.


I have used development systems where debugging compiler optimised
code was significantly more difficult. Not just debugging, but single
stepping through code which is the most basic test one should
do. Write the code, compile it, then single step through it to make
sure your code doesn't do anything _really_ stupid. Optimising also
can cost considerable compile time.


And I have seen cases where code that worked fine without optimisation
stopped working with optimisation. Often the real error was undefined
behavior in C code; the same problems would happen if you just
switched to a different compiler. Fact is that the code stopped
working with optimisation.


Developing with optimisation switched off and then trying to ship code
with optimisation switched on is asking for trouble. By switching
optimisation on, you _will_ introduce faults into the product you pass
to testing. Ask yourself if you can afford this.


Developing with optimisation switched on will make development take
longer, because compile times are longer and debugging is harder. Ask
yourself if you can afford this.


Optimisation should make execution times shorter. Measure how much you
gain. Chances are your code spends time in library routines that are
not recompiled anyway, or it spends time by just being stupid (in my
recent experience, most performance gains I achieved were by changing
code that did just stupid things), or it spends time in accessing
memory and any optimisations your C compiler does don't have any
effect at all. Ask yourself how much you will gain. How much time will
your customers safe, and how much will they lose if one single bug
introduced by optimising goes unnoticed.


Now the psychological effect: If you overrule the wishes of your
developers, you will feel good and they will feel bad. Developers who
feel bad develop bad code. Many of them know better how to develop
than you do. Most of them believe they know better how to develop than
you do. You are not paid for feeling good, you are paid for making the
developers feel good so that they produce good code.


If your developers are worth what you pay them, then they are worth
listening to. You have been developing years ago, they do it
know. Times change.

Return to the comp.compilers page.
Search the comp.compilers archives again.