Re: Speeding up libtool

[Robert Ögren]

Hi again Ralf,

I finally have some numbers for you. The script I used is available at
http://libtool-cache.sourceforge.net/libtool-cache-bench.sh

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

The test script does the following things for each configuration:

1. Unpack sources into a clean directory
2. Run aclocal, libtoolize etc etc
3. Run configure
4. Run make. At this stage, the cache databases are empty if caching is
used.
5. Run make clean and make. Only the time for make is measured, not for
make clean. Now the cache is fully populated, and additionally a few
things like message catalogs are not rebuilt. ("remake")
6. Remove libglib-2.0.la and relink it using make (about 50 objects are
linked along with some libraries) ("relink")
7. Remove gmain.lo and recompile it using make ("recomp")

After step 4 and 5 it also runs make check in a subdirectory to test
that everything seemed to be compiled OK. Note: I only run a few tests
since some don't seem to work when targetting win32.

Times with MinGW (win32) target (but running in a Cygwin shell):
(Running configure takes about 170 seconds)

I) With bash and libtool 1.5.10:
Without libtool-cache:
make    324 seconds
remake  302
relink  11.9
recomp  3.4

With libtool-cache:
make    146 (speedup=2.2)
remake  61 (speedup=5.0)
relink  1.2
recomp  1.2

II) With sh and libtool 1.5.10:
Without libtool-cache:
make    293
remake  272
relink  11.0
recomp  3.2

With libtool-cache:
make    134 (speedup=2.2)
remake  58 (speedup=4.7)
relink  1.2
recomp  1.2

III) With sh and libtool from CVS (1.1888 2005/03/18 15:57:13) 2.1a:
Without libtool-cache:
make    302
remake  251
relink  5.2
recomp  2.9

With libtool-cache:
make    160 (speedup=1.9)
remake  58 (speedup=4.3)
relink  1.2
recomp  1.2

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.

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.


Times with Cygwin target:

I) With bash and libtool 1.5.10:
Without libtool-cache:
make    295 seconds
remake  289
relink  13.4
recomp  3.1

With libtool-cache:
make    122 (speedup=2.4)
remake  55 (speedup=5.3)
relink  1.3
recomp  0.9

II) With sh and libtool 1.5.10:
Without libtool-cache:
make    267
remake  261
relink  12.5
recomp  2.8

With libtool-cache:
make    114 (speedup=2.3)
remake  53 (speedup=4.9)
relink  1.3
recomp  0.9

III) With sh and libtool from CVS (1.1888 2005/03/18 15:57:13) 2.1a:
Without libtool-cache:
make    254
remake  245
relink  5.9
recomp  2.7

With libtool-cache:
make    112 (speedup=2.3)
remake  53 (speedup=4.6)
relink  1.3
recomp  0.9

The test script was run with a command line like this:
TARGET_CYGWIN=y ./bench.sh > testout2 2> testlog2



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

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.

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

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.

Selected Cygwin package versions (I'm just using what Cygwin considers
stable/current):
autoconf-devel 2.59-1
automake-devel 1.9.2-1
bash 2.05b-16
binutils 20041229-1
coreutils 5.3.0-3
cygwin 1.5.13-1
gcc 3.3.3-3
gcc-mingw 20040810-1
libtool-devel 1.5.10-1
m4 1.4.2-1
make 3.80-1
mingw-runtime 3.7-1
sed 4.1.3-1
w32api 3.2-1


Conclusions:
- Using (a)sh instead of bash makes Libtool faster
- Libtool HEAD is faster than Libtool 1.5.10
- libtool-cache still makes a lot of difference :)
- Cutting down the time for compile mode would help a lot since it is 
invoked so many times.

Robert