Re: Performance issue of libtool-2.4.4

Richard Purdie <[email protected]>
Newsgroups gmane.comp.gnu.libtool.general
Message-ID <[email protected]>
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
> > 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.
> 
> 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+"$@"}
    func_run_hooks_result=$func_quote_for_eval_result

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
significantly.

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?

Cheers,

Richard


_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.