On czwartek 04 wrzesień 2003 09:46 am, Lars Gullik Bjønnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > | On czwartek 04 wrzesieÅ„ 2003 08:43 am, Lars Gullik Bjønnes wrote: > >> Kuba Ober <[EMAIL PROTECTED]> writes: > >> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote: > >> >> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 > >> >> (qt). This is making it somewhat painful to code :-( Could we think > >> >> about revisiting partial linking et al.? > >> | > >> | Unfortunately, after looking at it again, it seems that at least on > >> | RH9 partial linking gives almost no benefit (a couple percent maybe) > >> | :( > >> | > >> | I guess it may be worthwhile to look at linker code, try profiling and > >> | see where it spends most of its time :) > >> | > >> | I guess that qt 4 will reduce linking time somewhat, other than that > >> | boost is probably the scapegoat to blame. > >> > >> No it is not! > >> > >> The amount of debugging information in the object files are to blame. > | > | I stand corrected :) > | > | So the linker churns so long while generating debug info? > > No, the debugging info has already been created by the compiler (-g).
But linker generated the final, merged symbol tables in the binary that it spits out (be it .so or an exectuable). I guess it may be this that takes so much time. I think that per-object, the compiler overhead of adding a symbol table is not that significant (although actual measurements have to back this first). Yet, the linker has to read all debug info from object files (a lot of which is not needed in linking per se), merge it and append to the output binary. Considering that debug info in binary of lyx CVS can be on the order of 100mb, that gives a lot of work to be done by the linker. Just consider how long a cp of that file alone will take on your machine, now multiply by 10 ballparkly (tm) assuming that linker has 10 times more work to do than a simple copy of debug data, and that will get pretty close to actual time spent linking. This is all back-of-the-napkin kind of stuff -- personally I'd like to hear about differences in linking where linker is told to output debug info vs. leave it out. Maybe the sources can be compiled with debug info enabled, but the final linking could optionally discard all that cruft. That would make life much easier -- not every build has to be run in debugger, right? Cheers, Kuba Ober
