Re: speed up gnulib-tool a bit

[Bruno Haible]

Ralf Wildenhues wrote:
> For some invocations, gnulib-tool is rather slow[1], which impacts
> productivity a bit.  The following tries to improve things without
> sacrificing portability, while hopefully it doesn't compromise
> readability.  ;-)

Thanks a lot for the patches! They indeed boost performance a lot.
I'm applying them all, with minor tweaks regarding the whitespace placement
(break lines before a binary operator, not after it) and double-quotes
(put double-quotes even where they are not strictly necessary, but would be
necessary in an argument position).

Your files-rewrite.diff actually increases readability, IMO.

> First, `sort -u' is already used in gnulib-tool, so it would seem only
> consistent to drop `uniq' where possible, even as it does not lead to a
> noticeable speedup.

Yes. sort's -u option is specified by POSIX. Anyway, gnulib-tool already
assumes GNU sort.

> Then, the transitive closure algorithm need not walk any module names in
> the dependency graph more than once.  (Looking up and checking a module
> is rather expensive due to the file operations and fork&exec involved.)
> 
> Also, the rewriting of file names may be done in batch.  Note that this
> may cause the loop that calls `func_add_or_update' to be executed in a
> subshell, but this shouldn't matter: the function does not change any
> state.  (Should I provide a similar change for func_create_testdir?)

Calling func_add_or_update in a subshell is not good, because func_fatal_error
does not do the expected thing when executed in a subshell, and also when
we'll want to create synthetic ChangeLog entries, we need to pass detailed
information from inside func_add_or_update to its caller.

> And the include directives need only be read once.

Where can I download the shell script profiler that you used?

> PS: For the bootstrapping of gettext, it saves roughly 40s.

This is indeed a figure that I cannot ignore. :-)

> PPS: should the number of files used by a project exceed a few hundred,
> it may make sense to exploit bash3's `+=' with a func_append, in order
> to avoid the quadratic scaling associated with string enlargement:
> http://lists.gnu.org/archive/html/libtool-patches/2006-05/msg00016.html

Thanks for the tip. I'm adding such a func_append.

Bruno