Re: [RFC] Faster linking (-gsplit-dwarf, gold)
Luboš Luňák wrote: > Actually it turns out that gold can help even here, with the > --gdb-index option. > Wow. Can you roll that all into one update? Sounds like we'd be leaving a lot of productivity improvements on the table .. Cheers, -- Thorsten signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [RFC] Faster linking (-gsplit-dwarf, gold)
On Wednesday 27 of June 2018, Thorsten Behrens wrote: > Tangential question: anybody aware of something to prevent gdb from > trying to load _all_ symbols? The VS debugger is much more frugal > there initially. Actually it turns out that gold can help even here, with the --gdb-index option. I remember I tried that 4(?) years ago and back then it just moved the time from gdb to linking, which was pointless for the normal development cycle, but nowadays the small link time increase is probably worth it: before | gdb-index gdb symbols load time 51s | 16s libsclo link time6.159s | 7.758s libcslo.so size 207951K | 135315K That's all with gold and split debug enabled, and https://gerrit.libreoffice.org/#/c/56566/ . It seems to require binutils-2.25, which is from 2015. Just to add to the list, other things I've tried: * --threads doesn't seem to really do anything in practice. Even if I enable --preread-archive-symbols (which according to the source is the only thing it affects, besides compressed debuginfo), I can't see a difference. * --incremental reduces link time to about 4-5s, but appears to be unstable -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [RFC] Faster linking (-gsplit-dwarf, gold)
On 2018/06/27 12:35 AM, Thorsten Behrens wrote: Tangential question: anybody aware of something to prevent gdb from trying to load _all_ symbols? The VS debugger is much more frugal there initially. There is low hanging fruit in the main gdb load path. It inits memory with zeros and then overwrites it. (Not immediately either, it zeros tons of RAM and then comes back and overwrites it later, in the most cache-unfriendly manner possible). Which is a lot of time when it's loading tons of symbols. But when I reported that to the gdb devs, I was told to recompile gdb with another allocator (jemalloc maybe?) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [RFC] Faster linking (-gsplit-dwarf, gold)
On Wednesday 27 of June 2018, Thorsten Behrens wrote: > Tangential question: anybody aware of something to prevent gdb from > trying to load _all_ symbols? The VS debugger is much more frugal > there initially. set auto-solib-add off share See http://kdemonkey.blogspot.com/2007/12/memory-efficient-kde-4-debugging.html . Thinking of that, it probably wouldn't be too hard to make gdb autoload debugging info on-demand, e.g. for 'bt'. It might be worth trying. -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [RFC] Faster linking (-gsplit-dwarf, gold)
Miklos Vajna wrote: > This looks very promising, it's easy to get distracted while waiting > for sw (or I imagine sc) to re-link even during incremental > changes. A 32.433s -> 6.159s change sounds like a huge improvement > here. > Yeah. Am all for switching the defaults even. Tangential question: anybody aware of something to prevent gdb from trying to load _all_ symbols? The VS debugger is much more frugal there initially. Cheers, -- Thorsten signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [RFC] Faster linking (-gsplit-dwarf, gold)
Hi, On Tue, Jun 26, 2018 at 12:21:24PM +0200, Luboš Luňák wrote: > Some numbers: > normal | split > total debug build size 19120M | 14294M > CXXObject dir size 10320M | 8137M > libsclo.so size 461669K | 207951K > libsclo bfd link time 32.433s | 20.697s > libsclo gold link time 10.394s | 6.159s > gdb symbols load time 49s | 51s This looks very promising, it's easy to get distracted while waiting for sw (or I imagine sc) to re-link even during incremental changes. A 32.433s -> 6.159s change sounds like a huge improvement here. Thanks, Miklos signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
[RFC] Faster linking (-gsplit-dwarf, gold)
Hello, I've switched my LO debug build to use -gsplit-dwarf and together with using the gold linker this makes the build noticeably smaller and faster to link, for a negligible cost when starting gdb. So at https://gerrit.libreoffice.org/#/c/56416/ and https://gerrit.libreoffice.org/#/c/56417/ there are support for --enable-split-debug and --enable-gold that I intend to push. However, the actual reason for this mail is that I think that this should be the default for whoever can use it. I've been using it for a while on openSUSE42.3 (a year-old distro) with Clang5 and it seems that everything works just fine (including gdb and valgrind). Gold has been around for a couple of years and so has -gsplit-dwarf, so I'd naively expect that any distro capable of building current LO should have a decent support there as well. Has somebody any problematic experience with either of these? I've been pointed to http://document-foundation-mail-archive.969070.n3.nabble.com/configuring-gold-as-your-linker-td4217690.html by Noel, but the problems mentioned there are old and not very convincing. And note that I'm talking only about developer builds here (i.e. --enable-debug/dbgutil). I expect that distros would have problems with handling split debug info and the performance of gold doesn't really matter for them either. Some numbers: normal | split total debug build size 19120M | 14294M CXXObject dir size 10320M | 8137M libsclo.so size 461669K | 207951K libsclo bfd link time 32.433s | 20.697s libsclo gold link time 10.394s | 6.159s gdb symbols load time 49s | 51s -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
