This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libtool linking libgcj


aph@redhat.com wrote:

Alexandre Oliva writes:
> On Oct 8, 2003, Andrew Haley <aph@redhat.com> wrote:
> > > Nicholas S. Wourms writes:
> > >> What about splitting them up into 5 or 6 convenience libraries? > > > Okay, but it would be some considerable work, and how much improvemnt
> > should I expect? Why would splitting the library help?
> > It would avoid piecewise linking and huge command lines, except on
> systems whose linkers don't support --whole-archive or equivalent, in
> which libtool would have to extract the archives and then do piecewise
> linking.


Okay, but how would that help?  Most of the time seems to be in the
libtool shell cript, and I can't see why convenience libraries would
shorten that time.

I can't give a technical reason other then to say this is what the KDE folks did when faced with linking huge amounts of object files. From practical experience, I definitely notice an improvement when comparing a scenario of linking 100 objects in one go to one involving the linking of 10 conv libs containing 10 objects each. But you are right, most of the time is consumed by the routines in the libtool script which validate the object files and object scripts(.lo). As I mentioned before the new libtool 1.5 routines have been further optimized and streamlined in such a way that link times have been greatly reduced in most cases (as compared to libtool 1.4). Another idea, albeit a crazy one, would be to convert the libtool shell script to pure C, which would obviously improve performance significantly.


But to return to the kde example... They have also come up with another interesting way to reduce the number of object files at link time: they combine all the source files in a subdir into a single source file using "#include <source.cc>" directives and building it as a single object. This may not be good for debugging or even work at all for libjava, but if it could work, it would definitely cut down on the number of object files libtool needs to process, which in turn, would cut down on the length of time required to do the final link.

Just a few observations...

Cheers,
Nicholas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]