Re: [PATCH 0/5] speed up gnulib-tool some more

[Bruno Haible]

Hi Ralf,

> > Regarding part 1, I would like to put in a command-line option --no-cache
> > that preserves the old, slow but simpler code. It is good practice, for
> > every nontrivial optimization, to have a way to disable the optimization.
> > This helps in two situations:
> >   - When a bug crops up, and you want to know whether the cache introduced 
> > it.
> 
> This is no different from when a bug crops up in any other code: we
> debug it, by bisecting the git history or by inspecting the code, adding
> printf statements or using sh -x or the bash debugger.

But finding a bug through bisection takes much more time than it takes
to encircle it by specifying an option.

> Having two code paths for the same functionality in practice often means
> that the lesser-used will bit-rot over time.

This is not a problem. When we need the less optimized code (be it for
debugging, or as a starting point for a totally different optimization), we
can fix the tiny rotten pieces. This is way less work than to reinvent the
unoptimized code from scratch.

> If you are not confident enough in the new code, then please point out
> which parts you think are problematic.

It's not about confidence in the code. As I explained, I want the unoptimized
code to be available as an alternative. Like you would be upset if gcc did
not offer "-O0" and "-O1" any more.

> We can deal with unknown future problems when we get to them; thanks to
> version control we can easily see what needs to be reverted, should any
> changes, not just optimizations, turn out to be wrong turns.

This is not true. In 5 years from now, when the code has changed a bit
everywhere, it would take hours to revert a 5-year-old optimization.

> But that said, I wrote a patch that adds back the old code non-caching
> paths.

Thanks!


> I verified that the test dirs have no differences when compared with
>   diff -ruB -x autom4te.cache old new

The comparison should be without "-B" option:
    diff -r old new

An optimization is not supposed to introduce a change in behaviour.
With or without optimization, the results must be identical. (Do you
like it when a program compiled with "-O2" produces different results
than the same program compiled with "-O0"?)


> Another issue I thought of was cache variable name collision.

Good point!


Bruno