OK to get rid of scaddins?

[Michael Meeks]

Hi Michael,

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.

> > 	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

	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.

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

	All the best,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot