|
From: | Robert Yang |
Subject: | Re: Performance issue of libtool-2.4.4 |
Date: | Wed, 4 Feb 2015 17:56:52 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
Hello, I've found apart of the reason, for xz: libtool 2.4.2 2.4.5(before patched) (after patched) make -j1 9s 19s 11s 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 link create 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 <address@hidden>. 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.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.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. // RobertBob_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
[Prev in Thread] | Current Thread | [Next in Thread] |