HA: LLD benchmark results for all commits

Here is the result. This table contains a commit message, a SVN revision
number, time to link, size of the resulting Clang binary in each row.

That really looks awesome. And "graph hides some part of the table" is also true for me.
But anyways looks really cool, thanks for that !

Best regards,
George.

I created room above the first line so they don’t overlap. This is probably better than moving the graph to another sheet because I think if I do, some of you do not notice that there’s a graph at all.

I created room above the first line so they don't overlap. This is probably better than moving the graph to another sheet because I think if I do, some of you do not notice that there's a graph at all.

Ok, I also can`t understand where linker is going slower in table ? "C" column which is "Link time (seconds)" is lower and lower. Does it supposed to be inverted (1 - X) ?

Best regards,
George.

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.

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.

Ok.
There are few wierds also.
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.
I dont think its because of this lld changes. So i guess other llvm code also affects.

Best regards,
George.

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.

Thanks for doing this Rui!

Ok.
There are few wierds also.
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.
I dont think its because of this lld changes. So i guess other llvm code also affects.

That's about 2% which I'm inclined to think it could be just noise.

>> 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.

Thanks for doing this Rui!

>
> Ok.
> There are few wierds also.
> 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.
> I dont think its because of this lld changes. So i guess other llvm code
also affects.
>

That's about 2% which I'm inclined to think it could be just noise.

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.