Re: Speeding up libtool

[Ralf Wildenhues]

Hi Robert,

First I'd like to say many thanks for all your testing and valuable
feedback.  Will take a little while to work through all of it.

* Robert Ögren wrote on Fri, Mar 25, 2005 at 11:40:55PM CET:
> 
> I finally have some numbers for you. The script I used is available at
> http://libtool-cache.sourceforge.net/libtool-cache-bench.sh

OK.

> What it basically does is to build GLib 2.6.3 using different versions
> of libtool and with and without caching. As I said before, I'm usually
> using Cygwin but targetting MinGW (using gcc -mno-cygwin) to get native
> win32 binaries, and pretending the host is also mingw to avoid having to
> set up cross-compilation stuff. This works very well with one minor
> change in ltmain.sh: Replace $LTCC $LTCFLAGS with /usr/bin/gcc at the
> spot where it builds the wrapper exes from c source. (I don't expect you
> to change this in Libtool, I'm just explaining how I use it. Maybe there 
> is even a better way...)

It'd be interesting to know /why/ you have to change it, and what the
value of $LTCC and $LTCFLAGS are.

> The test script does the following things for each configuration:
*snip*
> Times with MinGW (win32) target (but running in a Cygwin shell):
> (Running configure takes about 170 seconds)
*snip results*
> 
> The test script was run with a command line like this:
> ./bench.sh > testout 2> testlog
> on an otherwise unloaded machine with antivirus software completely
> disabled. Note that the time for relinking and recompiling includes the
> time taken by make and by gcc.

OK, the testing method looks decent to me.

> The increase in time for the first compilation with Libtool HEAD is 
> caused by a large amount of sed calls, mainly by the "Quote evaled 
> strings" stuff from _LT_CONFIG_COMMANDS that is placed in config.status, 
> since config.status is invoked a few extra times on win32 to create 
> glib/glib.rc, gobject/gobject.rc, gmodule/gmodule.rc and 
> gthread/gthread.rc. Each config.status invocation cost about 10 seconds. 
> This is a minor thing, and could probably be fixed by adding them to 
> AC_CONFIG_FILES in configure.in with some win32 conditional stuff.

Hmm.  It's possible to do a similar trick here as in general.m4sh, it's
just not clear how much it will gain.  And whether some old shell starts
screaming again.  Something along the lines of (this will be in
config.status)

  var_xvalue=`eval $ECHO "X$var"`
  case $var_xvalue in
  *[\\\`\"\$]*)
    eval "lt_\$var=..        # sed invocation
    ;;
  *)
    eval "lt_$var=\$$var"
    ;;
  esac

Attached is a lightly tested patch for this.  The speedup of
config.status execution would be interesting.  For small projects
this might be more pronounced.

> Times with Cygwin target:
> 
*snip results*

> As I said in another mail there were some compatibility issues:
> 
> 1. glib's configure.in defines a few variables like LT_RELEASE, and 
> these names are forbidden with Libtool HEAD so I had to patch in a 
> m4_pattern_allow for these

Yes.  I think it would be better if glib changed their names, at least
in the long run.  The autotools have more-or-less gone towards reserving
their respective prefixes AC_, AT_, AS_, AM_, LT_ for the respective tools.
It makes sense to forbid others, e.g. because that way typos can be
diagnosed.  For the time being, m4_pattern_allow is a decent workaround.

> 2. configure.in did not have AC_LIBTOOL_WIN32_DLL which now is required
> for OBJDUMP to be set. However, even though I added AC_LIBTOOL_WIN32_DLL
> before AM_PROG_LIBTOOL, it did not work, but if I replaced the call to
> AM_PROG_LIBTOOL with LT_INIT([win32-dll]) it worked.

I think this is a bug in Libtool >= 2.0.  I'm not sure, though.

> 3. (I had to modify libtool-cache so it removes the libtool: compile:
> stuff that libtool HEAD prefixes output lines with)

Well, yeah, Libtool considered its output to be read by humans, not
parsed by more than our own testsuite.  It would, as already noted,
require very cautious audit for things like quoting level.

OTOH, if we can decide on putting a caching mechanism into libtool
proper, there might just be a simpler way than that.

> For Libtool HEAD I also rebuilt automake-2.59 and autoconf-1.9.2 so that
> Cygwin's Libtool files would not be picked up.

OK.

> Conclusions:
> - Using (a)sh instead of bash makes Libtool faster

ACK.  I would have thought the speedup was more than that, though.

> - Libtool HEAD is faster than Libtool 1.5.10

I'm quite happy to see this is true (for more than the examples I
tested).

> - libtool-cache still makes a lot of difference :)

Yes, quite true.  I am amazed at the amount of time spent in libtool. :(

> - Cutting down the time for compile mode would help a lot since it is 
> invoked so many times.

There is more than one side to this.  For one, the absolute times you
showed are much much larger for compilation than for linking.  OTOH,
usual developer cycle looks like:
  - edit a couple (1-3) files
  - compile these plus link
  - (maybe) test

and then it may make more sense to also look at how long that takes.
To get a rough idea of the relative speed: how many objects does glib
have?  Other way round: how long to compile just a couple of objects?

More conclusions:
- Improvements in cygwin/mingw fork() would be very noticeable.  :)
- configure is also quite slow (which becomes a pain if necessary to
  run frequently).  My patch should help a tiny bit with this as well.

Regards,
Ralf

less-quotesubsts
Description: Text document