<div dir="ltr">BTW, at some point we should set up a perf bot to keep eyes on runtime performance. "Just works" and "faster" would be two big reasons to switch the linker. We are currently checking only the former on every commit.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 16, 2015 at 1:17 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</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="">On Fri, Oct 16, 2015 at 1:08 PM, Rafael EspĂ­ndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Total number of function calls did not change. Previously, we call two<br>
> functions from one for-loop, and now they are called separately from two<br>
> for-loops. So the cost by this change is one for-each loop and no more than<br>
> that. If that's a complex data structure, I would probably care, but this is<br>
> a std::vector. I believe that that's extremely cheap.<br>
<br>
</span>Sure, and we are indeed still very fast. I just wanted to mention the<br>
possibility.<br>
<br>
btw, we do have a test in test/elf2/many-sections.s. Currently we take<br>
0.1s to link it, gold takes 21s :-)<br></blockquote><div><br></div></span><div>Nice! :)</div><div><br></div><div>Our code should be linear to the number of output sections. gold seems to be super-linear to that.</div></div></div></div>
</blockquote></div><br></div>