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
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
