[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance issue of libtool-2.4.4

From: Robert Yang
Subject: Re: Performance issue of libtool-2.4.4
Date: Wed, 11 Feb 2015 10:14:33 +0800
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Great, I verified that we nearly get the speed back:

When build xz:
          libtool-2.4.5  libtool-2.4.2
bash:        14s            13s
dash:        12s            11s

// Robert

On 02/10/2015 06:35 PM, Richard Purdie wrote:
On Mon, 2015-02-09 at 23:36 +0000, Richard Purdie 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

The issues come down to this commit:

libtool: rewritten over 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.

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.

To be more specific, if I take my "good" libtool and add:

func_options_prep ${1+"$@"}

it slows the build down by 0.5s on a 21s build. If I look at
func_options_prep and comment out the line:

     func_run_hooks func_options_prep ${1+"$@"}

I get the 0.5s back.

In func_run_hooks, if I comment:

     func_quote_for_eval ${1+"$@"}

I get the 0.5s back. The issue is all the quoting of the various return
values through all this looping. It doesn't appear to be hitting the
printf/sed in func_quote_for_eval which would be an obvious slow path,
its just the shear number of loops run through with the commandline
arguments. The change adds a number of calls to func_run_hooks, not just
the single test case I have above and all combined, it slows things down

So is there a way we can change things so its not calling
func_quote_for_eval all the time with all the looping that entails?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]