bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: libjava build times]


From: Ralf Wildenhues
Subject: Re: address@hidden: libjava build times]
Date: Thu, 5 May 2005 12:11:29 +0200
User-agent: Mutt/1.5.9i

Hi Joe, others,

* Ralf Wildenhues wrote on Wed, May 04, 2005 at 09:40:21PM CEST:
> * Ralf Wildenhues wrote on Wed, May 04, 2005 at 06:30:57PM CEST:
> > * Joe Buck wrote on Mon, May 02, 2005 at 08:01:49PM CEST:
> > >
> > > We really need something done about this problem, as it interferes
> > > with our ability to efficiently develop GCC.

Thank you for providing this example!  It shows the bottlenecks neatly.

I will tackle 'link mode' first, as I have worked on that previously and
know roughly what to do.  libtool-cache integration comes afterwards
(and probably in form of a small compiled program).

> > How many objects does libjava contain?  Rather 100 or 1000?  Do you
> > need relinking because of command line length?
> 
> I am compiling libjava ATM to see what happens.

OK, step 1: Executing the GCC provided libtool script for
libgcj0_convenience.la (warm cache) takes

  294.35user 45.47system 6:13.42elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (0major+6043907minor)pagefaults 0swaps

on my laptop (Pentium M 1.8), with --dry-run, so without doing any real work.

One significant bugger is the quadratic renaming loop, and all the
stuff that I already fixed in Libtool HEAD.  The attached rough patch
kills the loop and brings Libtool HEAD down to

  170.22user 10.41system 3:17.38elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (0major+1483544minor)pagefaults 0swaps

building the piecewise archiving cmdline better gets me

  133.80user 4.28system 2:36.78elapsed 88%CPU (0avgtext+0avgdata 0maxresident)k
  0inputs+0outputs (4major+747642minor)pagefaults 0swaps

I'm pretty sure I can get it quite a bit faster even.  The patches need
cleanup so that they use allowed file names and work properly in corner
cases as well, but those don't scale with the number of objects, so they
matter less.

If you are interested in further work: followup patches and cleaned up
versions of these will be posted to the libtool-patches list only.

Regards,
Ralf

Attachment: speedup5.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]