Re: Performance issue of libtool-2.4.4
Great, I verified that we nearly get the speed back:
When build xz:
libtool-2.4.5 libtool-2.4.2
bash:14s13s
dash:12s11s
// Robert
On 02/10/2015 06:35 PM, Richard Purdie wrote:
On Mon, 2015-02-09 at 23:36 +, Richard Purdie wrote:
On Mon, 2015-02-09 at 13:05 +, 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
Re: Performance issue of libtool-2.4.4
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 g...@gnu.org Date: Fri Feb 6 12:58:34 2015 + libtool: don't execute automake and autoconf on every invocation. // Robert correct that the issue is much more apparent with -j1. Optimized: 2.4.2 : 3:43.43 2.4.5 : 4:33.11 Non-Optimized: 2.4.2 : 1:21.21 2.4.5 : 2:05.48 We need a test case which is executed before every major release to make sure that a performance regression has not been introduced. Bob ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
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. 2.4.2 : 23.613 2.4.3 : 31.697 2.4.4 : 28.236 2.4.5 : 28.514 And here are timings for a non-optimize (-O0) compile with no debug symbols: 2.4.2 : 8.629 2.4.3 : 13.216 2.4.4 : 13.012 2.4.5 : 13.281 I see similar slowdowns on an Illumos-based system, so it is not specific to GNU/Linux. I'm using Ubuntu 12.04.3, we have added a few patches to libtool for cross building, but it seems these patches won't impact the speed so much since it works well when 2.4.2 (the same patches). // Robert It is curious that there is more impact for the optimized builds. Bob ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
Hello, After removing the two lines, libtool 2.4.5 is a little slower than 2.4.2 when using /bin/dash, but it is much slower than in bash, here is the data when compile xz: (make -j1) lt-2.4.2 lt-2.4.5(before patched) lt-2.4.5(after patched) dash 11s 21s13s bash 13s 30s21s We can see that dash is much faster than bash. (note, the data I had reported before for lt-2.4.5 after patched is 11s, but today is 13s, I think that it is because of the free disk space, the data is very stable in each day, I tried them several times). // Robert On 02/04/2015 10:56 PM, Robert Yang wrote: On 02/04/2015 10:48 PM, Bob Friesenhahn wrote: On Wed, 4 Feb 2015, Robert Yang wrote: When reporting a bug, please describe a test case to reproduce it and include the following information: host-triplet: $host shell: $SHELL compiler: $LTCC compiler flags: $LTCFLAGS linker: $LD (gnu? $with_gnu_ld) version:$progname (GNU libtool) 2.4.5 automake: `($AUTOMAKE --version) 2/dev/null |$SED 1q` autoconf: `($AUTOCONF --version) 2/dev/null |$SED 1q` Perhaps libtool is accidentially executing 'automake --version' and 'autoconf --version' every time it is executed? That would certainly lead to a huge slowdown. Thanks, yes, you are right, after remove the two lines, the time is the same as remove the whole block (11s). // Robert Bob ___ https://lists.gnu.org/mailman/listinfo/libtool ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
Hello,
I've found apart of the reason, for xz:
libtool 2.4.2 2.4.5(before patched) (after patched)
make -j19s 19s11s
Remove the following lines from libtool, then the compile will be
much faster, the problem is the variable like $host, $SHELL in
the long_help_message would make shell very slow:
=== Removed lines ===
# Additional text appended to 'usage_message' in response to '--help'.
long_help_message=$long_help_message
MODE must be one of the following:
clean remove files from the build directory
compile compile a source file into a libtool object
execute automatically set library path, then run a program
finish complete the installation of libtool libraries
install install libraries or executables
linkcreate a library or an executable
uninstall remove libraries from an installed directory
MODE-ARGS vary depending on the MODE. When passed as first option,
'--mode=MODE' may be abbreviated as 'MODE' or a unique abbreviation of that.
Try '$progname --help --mode=MODE' for a more detailed description of MODE.
When reporting a bug, please describe a test case to reproduce it and
include the following information:
host-triplet: $host
shell: $SHELL
compiler: $LTCC
compiler flags: $LTCFLAGS
linker: $LD (gnu? $with_gnu_ld)
version:$progname (GNU libtool) 2.4.5
automake: `($AUTOMAKE --version) 2/dev/null |$SED 1q`
autoconf: `($AUTOCONF --version) 2/dev/null |$SED 1q`
Report bugs to bug-libt...@gnu.org.
GNU libtool home page: http://www.gnu.org/software/libtool/.
General help using GNU software: http://www.gnu.org/gethelp/.
==
I think that another 2s gaps is caused by:
func_hookable func_options
func_options ()
{
$debug_cmd
func_options_prep ${1+$@}
eval func_parse_options \
${func_options_prep_result+$func_options_prep_result}
eval func_validate_options \
${func_parse_options_result+$func_parse_options_result}
eval func_run_hooks func_options \
${func_validate_options_result+$func_validate_options_result}
# save modified positional parameters for caller
func_options_result=$func_run_hooks_result
}
mainly because of:
eval func_parse_options \
${func_options_prep_result+$func_options_prep_result}
I'm still trying to figure out why.
// Robert
On 02/04/2015 09:11 AM, Robert Yang wrote:
On 02/03/2015 10:31 PM, Bob Friesenhahn wrote:
On Tue, 3 Feb 2015, Robert Yang wrote:
Sorry, I was wrong, tt seems that libtoolize is not the key, but libtool,
when compile cairo-1.12.18:
libtool 2.4.2libtool 2.4.5
configure: 31s32s
compile:54s64s
The libtool 2.4.5 costs 10 more seconds. I'm debugging on it, any suggestion
is appreciated.
The build slowdown must not be my imagination then. I had attributed the
slowdown to other factors. Recently I noticed that build times for my own
project were significantly longer than I remember.
Previously libtool was heavily optimized to reduce the number of forks
(execution of child process). This optimization should still be present in
2.4.2. Any additional forks will result in a slower build.
It is not necessary to libtoolize a package in order to test its build
performance with different libtool versions. You can specify LIBTOOL in the
environment (see the Makefiles) such that it points to the uninstalled libtool
in a libtool build tree.
We run autoreconf for the package automatically to make sure that we can
build most of the autotools packages successfully, and autoreconf will
run libtoolize when needed, if we don't run autoreconf, then a few of the
packages will fail to build, now we upgrade libtool from 2.4.2 to 2.4.4/2.4.5,
it takes more time to build, I will try 2.4.3.
// Robert
Bob
___
https://lists.gnu.org/mailman/listinfo/libtool
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
On 02/04/2015 10:48 PM, Bob Friesenhahn wrote: On Wed, 4 Feb 2015, Robert Yang wrote: When reporting a bug, please describe a test case to reproduce it and include the following information: host-triplet: $host shell: $SHELL compiler: $LTCC compiler flags: $LTCFLAGS linker: $LD (gnu? $with_gnu_ld) version:$progname (GNU libtool) 2.4.5 automake: `($AUTOMAKE --version) 2/dev/null |$SED 1q` autoconf: `($AUTOCONF --version) 2/dev/null |$SED 1q` Perhaps libtool is accidentially executing 'automake --version' and 'autoconf --version' every time it is executed? That would certainly lead to a huge slowdown. Thanks, yes, you are right, after remove the two lines, the time is the same as remove the whole block (11s). // Robert Bob ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
On 02/02/2015 10:19 PM, Bob Friesenhahn wrote: On Mon, 2 Feb 2015, Robert Yang wrote: Hello libtool, It seems that libtool (2.4.4) has increased the packages build time, after a rough investigation, it maybe because new libtoolize needs run a m4 command: Did you time 'libtoolize' and compare the timings with 2.4.4 to the release you were using before? Libtoolize is not normally considered to be part of package build time since packages usually already come 'libtoolized' (using some random version of libtool). Bob Sorry, I was wrong, tt seems that libtoolize is not the key, but libtool, when compile cairo-1.12.18: libtool 2.4.2 libtool 2.4.5 configure: 31s 32s compile:54s 64s The libtool 2.4.5 costs 10 more seconds. I'm debugging on it, any suggestion is appreciated. // Robert ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Performance issue of libtool-2.4.4
On 02/03/2015 10:31 PM, Bob Friesenhahn wrote: On Tue, 3 Feb 2015, Robert Yang wrote: Sorry, I was wrong, tt seems that libtoolize is not the key, but libtool, when compile cairo-1.12.18: libtool 2.4.2libtool 2.4.5 configure: 31s32s compile:54s64s The libtool 2.4.5 costs 10 more seconds. I'm debugging on it, any suggestion is appreciated. The build slowdown must not be my imagination then. I had attributed the slowdown to other factors. Recently I noticed that build times for my own project were significantly longer than I remember. Previously libtool was heavily optimized to reduce the number of forks (execution of child process). This optimization should still be present in 2.4.2. Any additional forks will result in a slower build. It is not necessary to libtoolize a package in order to test its build performance with different libtool versions. You can specify LIBTOOL in the environment (see the Makefiles) such that it points to the uninstalled libtool in a libtool build tree. We run autoreconf for the package automatically to make sure that we can build most of the autotools packages successfully, and autoreconf will run libtoolize when needed, if we don't run autoreconf, then a few of the packages will fail to build, now we upgrade libtool from 2.4.2 to 2.4.4/2.4.5, it takes more time to build, I will try 2.4.3. // Robert Bob ___ https://lists.gnu.org/mailman/listinfo/libtool
Performance issue of libtool-2.4.4
Hello libtool, It seems that libtool (2.4.4) has increased the packages build time, after a rough investigation, it maybe because new libtoolize needs run a m4 command: # Save the command pipeline results for further use by callers of # this function. func_extract_trace_result=`$ECHO $_G_mini \ |$M4 -daq --prefix $_G_m4_traces - $@ 21 1/dev/null \ |$SED -n -e $_G_transform` This may increase the build time (just a rough guess), does any other one also notice the performance issues, please ? I will go on investigating on it. Any suggestion is appreciated. -- Thanks Robert ___ https://lists.gnu.org/mailman/listinfo/libtool
