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
