[Top][All Lists]

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

Re: Performance issue of libtool-2.4.4

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


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

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: <>.
General help using GNU software: <>."

I think that another 2s gaps is caused by:
func_hookable func_options
func_options ()

    func_options_prep ${1+"$@"}
    eval func_parse_options \
    eval func_validate_options \

    eval func_run_hooks func_options \

    # save modified positional parameters for caller

mainly because of:
    eval func_parse_options \

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.

// Robert



reply via email to

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