Re: OK to get rid of scaddins?

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.