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. > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice