Re: OK to get rid of scaddins?

On Tue, Feb 14, 2012 at 10:52:31AM +0000, Michael Meeks wrote:
> On Mon, 2012-02-13 at 16:06 +0100, Michael Stahl wrote:
> > > > (of course i don't care if you do it for a special "merged libs" mode,
> > > > but C++ development is already a sufficiently unproductive activity that
> > > > we shouldn't make it even more so...)
> > >
> > >   Is it necessary to build with full debug enabled ? how slow is it
> > > really ? [ if it takes ten minutes - how slow is it to re-build with
> > > just the bits you want symbols for & re-run whatever you're
> > > debugging ?].
> >
> > i find it works quite well with 8GB of RAM, except that linking takes
> > much longer (and you better not have 3 unit tests crash concurrently
> > otherwise gdb will lock up the box for 15 minutes until OOM killer is
> > invoked...).
>
>       So - can you give some concrete ideas of time & space it is taking to
> link our shared libraries ? and also the growth in size that we get -
> what is the stripped vs. non-stripped output ? Mark prolly has some
> great insights as to how to improve that.

Actually I was working on reducing the debug size for distro packaging,
that won't immediately help in this case. There is some effort to reduce
the size of the generated debug info between compiler and linker:
http://gcc.gnu.org/wiki/DebugFission

> > >   I wonder if the new 'gold' linker will help performance wise - have you
> > > tried it ?
> >
> > no, but the problem is really the space that the object files take up:
> > they don't fit all into RAM cache, and ld is blocked on I/O most of the
> > time (in tail_build).
>
>       If we have > 8Gb of debug symbols per module there is a -real- problem
> here; Lubos was talking of using some more magic / smaller debug option
> in the past: -gdwarf-4

In general using DWARF4 will allow the compiler to use a more compact
representation. So if at all possible make sure you use -gdwarf-4 (on
some distros this is already the default).
 
>       Are you using that ? I believe we turned it off by default again for
> some reason or other: potentially we want to add a check for a tolerably
> recent toolchain and debugger on the system before defaulting to that
> [ it supposedly saved 30% of the size ], but you need gdb 7.3 really.

Some tools don't yet support the new DWARF4 .debug_types sections. In
that case you can use -gdwarf-4 -fno-debug-types-section to get the more
compact DWARF4 representation except for the separate .debug_types.
(This is the default for Fedora now.)

>       Either way, it sucks to hinder ourselves from creating a more efficient
> library structure because of un-necessary performance problems in the
> toolchain ;-)

The toolchain is constantly being updated to make the debuginfo more
expressive and more compact, but it definitely helps to use the latest
and greatest (gcc 4.6 or the 4.7-pre-release highly recommended).

And for C++ linking speedups switching to the gold linker should also
help.

Cheers,

Mark