libtool
[Top][All Lists]
Advanced

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

Re: Performance issue of libtool-2.4.4


From: Peter Rosin
Subject: Re: Performance issue of libtool-2.4.4
Date: Mon, 09 Feb 2015 14:57:11 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2015-02-09 14:05, Richard Purdie wrote:
> On Mon, 2015-02-09 at 10:45 +0800, Robert Yang wrote:
>> On 02/06/2015 10:46 PM, Bob Friesenhahn wrote:
>>> On Fri, 6 Feb 2015, Robert Yang wrote:
>>>
>>>>
>>>>
>>>> On 02/06/2015 12:12 PM, Bob Friesenhahn wrote:
>>>>> I am not seeing quite the difference between libtool releases that you are
>>>>> although I see a big slowdown starting with 2.4.3.  These timings are for
>>>>> optimized builds of GraphicsMagick on a 12-core GNU/Linux system using -j 
>>>>> 12:
>>>>
>>>> I think that we can't see obviously slowdown by "make -jN",
>>>> but "make -j1" will. And bash is much slower than dash, I'm trying to
>>>> figure out why.
>>>
>>> It seems like this issue is already corrected in the source tree but you are
>>
>> Yes, I think that the git repo has fixed the problem:
>>
>> commit 408cfb9c5fa8a666917167ffb806cb19deded429
>> Author: Gary V. Vaughan <address@hidden>
>> Date:   Fri Feb 6 12:58:34 2015 +0000
>>
>>      libtool: don't execute automake and autoconf on every invocation.
> 
> 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?

IIRC, there was prior work to make func_compile appear as early as
possible. With this change, there are a lot of functions to parse
before getting to func_compile (and all of them are not needed that
early in the script, I think, but I have not verified that). Maybe
that can explain the difference? You could try to manually move
functions that are not needed by func_compile to appear after
func_compile and see if that makes a difference.

Cheers,
Peter




reply via email to

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