<div dir="ltr"><div class="gmail_extra">Yeah, benchmark is tricky. If your CPU is cold at beginning, the first few runs could be faster than the following runs of the same program because of Intel Turbo Boost, for example.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If there's still 2% difference, I'd like to know if it's caused by this patch. I didn't expect that this patch would slow down the linker by a few percent. I believe this patch is negligible in terms of linker performance, unless your program is using tons of common symbols.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 12, 2017 at 5:30 PM, Shoaib Meenai <span dir="ltr"><<a href="mailto:smeenai@fb.com" target="_blank">smeenai@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can't reproduce the slowdown anymore :( I'm measuring by running the link in<br>
question 16 times with `time` and taking the average of the total time<br>
reported. Yesterday, I was consistently seeing the 20% slowdown I mentioned.<br>
Today that difference has dropped to 2%. Perhaps my runs yesterday got unlucky<br>
with CPU load from other processes or something similar.<br>
<br>
Sorry for the false alarm. I'll still try to switch my library to using<br>
-fno-common though, just for general cleanliness. Thanks for all the replies!<br>
<div class="HOEnZb"><div class="h5"><br>
On 9/12/17, 2:51 PM, "Rafael Avila de Espindola" <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
<br>
    Shoaib Meenai <<a href="mailto:smeenai@fb.com">smeenai@fb.com</a>> writes:<br>
<br>
    > It's written in C, and it has 325 common symbols.<br>
    ><br>
    > I only read up on common symbols today, so please correct me if my<br>
    > understanding is off. From what I've read, you'll end up with a common symbol<br>
    > in your object file if you have an uninitialized non-static global variable,<br>
    > e.g. (in the global scope):<br>
    ><br>
    > int x;<br>
    ><br>
    > If you mark the variable static, or if you explicitly zero-initialize it,<br>
    > it'll end up in bss instead of COMMON. You can also use -fno-common to force<br>
    > the use of bss, and C++ does so by default.<br>
    ><br>
    > I understand that COMMON symbols were originally devised to deal with people<br>
    > writing `int x` instead of `extern int x` in headers. My library doesn't have<br>
    > that problem; the `int x` form is used only in source files, and the intent is<br>
    > to define a variable and have it be automatically zero-initialized. I was<br>
    > hoping that if a variable was preceded by an extern declaration, e.g.<br>
    ><br>
    > extern int x;<br>
    > ...<br>
    > int x;<br>
    ><br>
    > the compiler would place it in bss instead of COMMON, but that doesn't appear<br>
    > to be the case.<br>
    ><br>
    > I'll try compiling my sources with -fno-common. This definitely seems like<br>
    > something a lot of libraries could run into though, since it looks like all<br>
    > you need to trigger it is an uninitialized global variable.<br>
<br>
    Your understanding is correct. As Rui points out, allocating 325<br>
    sections cannot be directly slowing down lld so much.<br>
<br>
    My first guess would be that by making DefinedCommon larger the patch<br>
    could have increased the size of Symbol, but that was not the case since<br>
    SharedSymbol was still bigger.<br>
<br>
    How stable is the benchmark across lld versions? What time do you get<br>
    with top of tree?<br>
<br>
    Cheers,<br>
    Rafael<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>