[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/5] speed up gnulib-tool some more
From: |
Bruno Haible |
Subject: |
Re: [PATCH 0/5] speed up gnulib-tool some more |
Date: |
Mon, 8 Feb 2010 01:24:28 +0100 |
User-agent: |
KMail/1.9.9 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH 0/5] speed up gnulib-tool some more,
Bruno Haible <=