[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
- Re: Performance issue of libtool-2.4.4, (continued)
- Re: Performance issue of libtool-2.4.4, Robert Yang, 2015/02/03
- Re: Performance issue of libtool-2.4.4, Robert Yang, 2015/02/04
- Re: Performance issue of libtool-2.4.4, Bob Friesenhahn, 2015/02/04
- Re: Performance issue of libtool-2.4.4, Robert Yang, 2015/02/04
- Re: Performance issue of libtool-2.4.4, Robert Yang, 2015/02/05
- Re: Performance issue of libtool-2.4.4, Bob Friesenhahn, 2015/02/05
- Re: Performance issue of libtool-2.4.4, Robert Yang, 2015/02/06
- Re: Performance issue of libtool-2.4.4, Bob Friesenhahn, 2015/02/06
- Re: Performance issue of libtool-2.4.4, Robert Yang, 2015/02/08
- Re: Performance issue of libtool-2.4.4, Richard Purdie, 2015/02/09
- Re: Performance issue of libtool-2.4.4,
Peter Rosin <=
- Re: Performance issue of libtool-2.4.4, Richard Purdie, 2015/02/09
- Re: Performance issue of libtool-2.4.4, Richard Purdie, 2015/02/10
- Re: Performance issue of libtool-2.4.4, Gary V. Vaughan, 2015/02/10
- Re: Performance issue of libtool-2.4.4, Richard Purdie, 2015/02/10
- Re: Performance issue of libtool-2.4.4, Robert Yang, 2015/02/10
- Re: Performance issue of libtool-2.4.4, Gary V. Vaughan, 2015/02/10
- Re: Performance issue of libtool-2.4.4, Peter Johansson, 2015/02/06
- Re: Performance issue of libtool-2.4.4, Peter Rosin, 2015/02/06
- Re: Performance issue of libtool-2.4.4, Gary V. Vaughan, 2015/02/06
- Re: Performance issue of libtool-2.4.4, Peter Rosin, 2015/02/06