OK to get rid of scaddins?

[Michael Stahl]

On 13/02/12 15:47, Michael Meeks wrote:
> 
> On Mon, 2012-02-13 at 12:38 +0100, Michael Stahl wrote:
>> the sc, sd, sw libraries already take forever to link with full debug,
> 
> 	You link with full debug ? :-)

well i was actually surprised once that i do, but soon found out that
somebody has changed gbuild.mk so that it enables debug when
--enable-dbgutil is active.  i'm not sure if _that_ is a good idea
(after all we have --enable-debug as well, and i think it broke
--enable-dbgutil --disable-debug), but actually i got used to always
having symbols everywhere, because that way i get useful backtraces etc.
on hard-to-reproduce crashes and deadlocks, which is quite useful.

>> and adding more stuff to them would also impact startup performance for
>> the respective application.
> 
> 	Not necessarily; by merging libraries together we can potentially
> improve startup performance a fair bit. Fewer scattered libraries on
> disk means better access times, more scope for LTO, and faster run-time
> linking.

sounds plausible in principle, but to me "scaddins" doesn't sound like
something needed at startup; i think the fastest startup can only be
attained by only loading what is actually necessary to start.

>> (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...).

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

> 	Regards,
> 
> 		Michael.
>