From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@cygnus.com>
To: law@cygnus.com
Cc: ddt@crack.com, egcs@cygnus.com
Subject: Re: Incremental linking
Date: Fri, 10 Apr 1998 12:35:00 -0000
Message-id: <199804101510.LAA11307@subrogation.cygnus.com>
References: <29607.892184128@hurl.cygnus.com>
X-SW-Source: 1998-04/msg00443.html

   Date: Thu, 09 Apr 1998 22:55:28 -0600
   From: Jeffrey A Law <law@cygnus.com>

     > A big problem seems to be that the output file is a whopping 12Mb, and the
     > *.o files take up a healthy 50Mb themselves.  This stuff is partially
     > bloated because of the size of the debugging info added by -g.  We've
     > noticed that MSVC puts the debugging symbols in a seperate file.  Perhaps
     > they did this to speed up linking? 
   Quite possible.  Dealing with debug symbols is a significant amount
   of time for the linker.  These days it's mostly the IO costs I 
   suspect (contrast to a.out style stabs which are computationally
   expensive as well as IO expensive).  You aren't using a.out are you?!?

The GNU linker since version 2.7 compresses ELF stabs debugging
information, which means that it does interpret the stabs strings, and
there are computational costs.  I do not know how significant they
are.

You can see this compression in effect when the 50MB of .o files
become a 12MB output file.  I expect that most of that change is due
to debugging compression.  You can confirm this, if you care, by
running the linker with the --traditional-format option, which turns
off the debugging compression.


To shorten the link time, I agree with Jeff: use shared libraries if
they are a possibility.

Also, the linker is a heavy memory user.  Check the memory size of the
linker process while it is running; if it is being forced out to swap,
then adding RAM may be a cheap way to speed up linking.

I would not expect using -r to shorten your link time significantly.
It will cut down on the number of open and read calls, and there will
be some reduction in the number of global symbols, but the linker
still has to process basically the same amount of data.  You can also
cut down the number of open and read calls to a lesser degree by using
archives, perhaps with the --whole-archive option if appropriate for
your application.


In general, I believe that changing gdb to read debugging information
from the .o files would permit a significant decrease in link time, at
the cost of an increase in debugging time.  It would be good if
somebody looked into adding that feature to gdb.

Ian