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
