<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 2:34 PM, Yin Ma via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">Hello, <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I understand shared linked is currently a lot slower than static linked.<u></u><u></u></p><p class="MsoNormal">However, for debug build, where speed is not required. Shared link has <u></u><u></u></p><p class="MsoNormal">A lot of advantage. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Static linked clang/llvm on linux is 17G, shared build is only 1.5G.</p></div></div></blockquote><div><br></div><div>Assuming you're talking about a debug build, you can probably get that down a lot with at least -fdebug-types-section or with -gsplit-dwarf.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"> On a mainstream <u></u><u></u></p><p class="MsoNormal">linux host machine with 12G memory, only –j1 can be used to finish final linking step.</p></div></div></blockquote><div><br></div><div>If you use Ninja, I believe it has a separate pool limit you can tweak for linking (but, again, with -fdebug-types-section or -gsplit-dwarf, you might make the link steps more palatable (-gsplit-dwarf is probably the better/more important choice, though))<br><br>But I'd be surprised if the limit is that low - are you using gold? Or binutils ld? Gold is a good/better choice here, and usually I only end up using about a GB of RAM per linking process I Think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">With –j8 the linux will link the linking. With 17G footprint, copying from build folder<u></u><u></u></p><p class="MsoNormal">to install folder is also very slow. </p></div></div></blockquote><div><br></div><div>Solid state, on spinning disks? Solid state would help a bit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">So it is very reasonable to set <u></u><u></u></p><p class="MsoNormal">BUILD_SHARED_LIBS=ON as default for debug build because it would improve usability<u></u><u></u></p><p class="MsoNormal">and performance.</p></div></div></blockquote><div><br>The thing is, the performance tradeoff also hits test execution time. At least last time I checked (granted, on a 32 core, 64GB of RAM machine) the build time improvement (on a clean build) with shared libs was not saved by a single execution of the regression test suite (which took longer than the savings). Let alone on an incremental build... if I remember my numbers correctly.<br><br>Not sure whether it's the right call to change the default - people can change their own settings easily enough.<br><br>- Dave</div></div></div></div>