<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 15, 2016 at 4:04 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 15, 2016 at 3:59 PM, George Rimar via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> Well, from November 1st to the end of December, the linker got slower by about 10%, but you cannot attribute that decrease to any single change. That's the result of accumulation, and that's why I wrote it tends to getting slower. All the accumulation was offset by a single change, which is the string table optimization patch, though.<br>
<br>
</span>Thanks for doing this Rui!<br>
<span class=""><br>
><br>
> Ok.<br>
> There are few wierds also.<br>
> 257731 "[ELF/AArch64] Support R_AARCH64_LDST128_ABS_LO12_NC relocation." looks to have 0.425998862 link time what is greater than previous 0.415870616.<br>
> I dont think its because of this lld changes. So i guess other llvm code also affects.<br>
><br>
<br>
</span>That's about 2% which I'm inclined to think it could be just noise.<br></blockquote><div><br></div><div>I agree with that. If one result happens to be 1% faster and the next one is 1% slower, they differ by 2%. We need to take data points around them to draw a conclusion. But the data point is at very end of the graph which we do not have enough points around it, so I think it is risky to get any conclusion from it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
</font></span></blockquote></div><br></div></div>