<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 10, 2017 at 1:01 PM, Rui Ueyama via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No. GHC **runtime** linker is much slower when handling *.a files (and this is exactly the culprit of this whole story) since it goes through the whole archive and links each object module separately doing all resolutions and relocations and trampolines, than when linking already prelinked big *.o file.<br></blockquote><div><br></div></span><div>Looks like I still do not understand why a .a can be much slower than a prelinked .o. As far as I understand, "ld -r" doesn't reduce amount of data that much. It doesn't reduce the number of relocations, as relocations in input object files are basically passed through to the output. It doesn't reduce the number of symbols that much, as the combined object file contains a union of all symbols appeared in the input files. So, I think the amount of data in a .a is essentially the same as a prelinked .o. I wonder what can make a difference in speed.</div></div></div></div></blockquote><div><br></div><div>I can't speak for Haskell, but ld -r can be useful for speeding up C++ links, because it acts as a pre-merging step for duplicate comdats. Consider a library that uses many instantiations of the same template with the same type. An archive will contain many copies of the template, but a relocated object file will only contain one.</div></div></div></div>