address@hidden: libjava build times]

[Joe Buck]

In response to a recent challenge from Peter O'Gorman:

Peter: please consider the attached to be a libtool bug report.
We really need something done about this problem, as it interferes
with our ability to efficiently develop GCC.

--- Begin Message --- Subject: libjava build times Date: Sat, 30 Apr 2005 20:48:29 -0700 User-agent: Mutt/1.4.1i

On Sat, Apr 30, 2005 at 10:33:43AM +0100, Andrew Haley wrote:
> OK, so the low-hanging fruit that remains is the libtools script and
> the linker.  In the latter case, it seems that the big link causes
> severe problems with small memory systems.

I did some experiments today just to see what kind of time it actually
takes to compile the actual objects, and thus how much time is on the
table to be retrieved from libtool.

The following was performed on a 2.3Ghz G5, with 2G of ram.  So I'm
not swapping and in fact everything can reside in cache.  I.e. just
about the ideal setup.  There are in fact two cpus, but I'm not using
the -j option to make at all.

I began by building the whole of libjava, and then using find to 
delete all of *.o *.lo *.a *.la.  I then timed rebuilding the library:

  2248.43user 661.42system 47:46.01elapsed 101%CPU (0major+47501310minor)

Next, I canibalized the makefile in order to bypass libtool, and invoke
gcc directly.  My solution does assume gnu ld and ar, but this is just
a test after all.

  -O2 -fPIC compile
  824.80user 86.88system 15:11.69elapsed 99%CPU (0major+7102491minor)

  .so link + .a create
  10.45user 9.59system 0:19.97elapsed 100%CPU (0major+851815minor)

Now, unless I've done something drastically wrong, it appears as if we
are spending 2/3 of our time in the libtool script.

Test makefiles attached for the record.


r~

test-make.tar.gz
Description: GNU Zip compressed data

--- End Message ---