Re: Performance issue of libtool-2.4.4

[Gary V. Vaughan]

Hi Richard,

> On Feb 9, 2015, at 11:36 PM, Richard Purdie <address@hidden> wrote:
> 
> On Mon, 2015-02-09 at 13:05 +0000, Richard Purdie wrote:
>> In an effort to get to the bottom of this I made a git bisection, timing
>> the performance of building xz with make -j1 using each different
>> libtool.
>> 
>> The issues come down to this commit:
>> 
>> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0a42997c6032b9550a009a271552e811bfbcc430
>> 
>> libtool: rewritten over funclib.sh instead of general.m4sh.
>> 
>> Before that, I get a time of about 20s, after it, 39s. If I cherry-pick
>> in the fix in master mentioned above, I get 27s.
>> 
>> So whilst things are better (thanks!), the above change is still causing
>> a regression in the performance somewhere else. Any ideas what else in
>> that rather large change may be causing this?
> 
> To further narrow this down, of the changes in the above commit, the
> problem appears to be in the changes to the option parsing code. I've
> included the diff below which if I apply on top of the above, I get the
> speed back. I've left the func_split_short_opt/func_split_long_opt code
> in there but that is worth a tiny part of the speed, the issues are
> around the addition of the func_options call.

Thanks for the analysis and patch.

> As yet I don't know enough about the code in question to know why this
> is an issue but traces of libtool show a lot more looping in code to do
> with argument parsing and quoting.

For background, one of the larger changes between 2.4.2 and 2.4.3 was to
move from separately maintained options code in raw shell in libtoolize and
generated by m4 in libtool, to the unified generalized shell options parser
from bootstrap, kept in gl/build-aux/options-parser.  The benefits of this
include time saved in maintenance of only one options parsing implementation
over three separate ones (I maintain bootstrap too), and a lot more flexibility
in the shell function hooking code -- ultimately, this will enable splitting
libltdl into a separate project, which can inject ltdl specific code into
the already installed libtoolize script.

I was aware this would result in a somewhat slower libtool, though I'm
surprised that it is as large a difference as you have timed.  I'd be very
happy to find a way to patch gl/build-aux/option-parser or its clients to
regain some of that speed, but I'm extremely reluctant to revert to the
hokey mishmash of m4 and shell that 2.4.2 was using purely for the sake of
speed -- it might be that for extremely large projects you'll want to stick
with 2.4.2 until we find a way to restore the necessary speed in some future
release?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)