Re: Justifying Optimization

Robert A Duff wrote:
> Joachim Durchholz <joachim_d@gmx.de> writes:
>>Additional testing with the optimizer turned on will just find a lot
>>of bugs that were never relevant in debug code - why fix them?
>
> Those bugs might rear their ugly heads when you upgrade to a new
> compiler version. Or when you make seemingly-irrelevant changes in
> nearby code. Or when you port your program to a new machine or OS.
> (How many times have a I seen projects where portability was
> explicitly "not important" but it turned out to important later one?)


I know these problems. It's just that the decision is between "don't
test everything" and "scrap the project". Or, put another way: the
resources for creating software are limited. Portability issues
should be paid for when portability gives an advantage. The question
is whether late fixing of portability bugs is really that much more
expensive. It's rare that a portability problem requires a rewrite of
unrelated or even nearby parts of code; it's mostly micro-idioms. Why
not postpone this to the time when it becomes relevant?


> Seems to me, you'd like to find those optimizer-triggered bugs
> earlier rather than later.


I used to have this stance myself, but in practice, I'm happy to have
all known bugs fixed when the software gets out of the door. Looking
for and fixing yet-unknown bugs is definitely low priority, doing the
same for currently inconsequential bugs is least priority. I'm pretty
sure that I'm not in the only shop that's working under these
constraints. That may be sad, but it's a fact of life, and I'm less
interested in getting to an unreachable ideal world, I prefer thinking
about improvements here and now.


Regards,
Joachim

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