llvm dev - Mar 2016 - LLD performance w.r.t. local symbols (and --build-id)

On Wed, Mar 16, 2016 at 9:05 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> On 16 March 2016 at 01:34, George Rimar <grimar at accesssoftek.com>
wrote:
> > Slowdown by "[ELF] - Early continue in
> InputSectionBase<ELFT>::relocate().
> > NFC." looks wierd for me. I do not see any reasons for any impact
on
> > perfomance by this change.
>
>
> I think it is just because the continue is unlikely and now there is
> an early check of offset.
>
> > Good news is that since it was NFC it can easily be reverted. But I
think
> > slowdown in results is unrelative with that change and reverting will
not
> > give us 2-3% boost back.
>
> I don't think we should revert it right now. There are a few big
> changes I would like to try to the relocation processing code.
>
Agreed. Unless your code changes algorithm, you don't need to worry too
much about performance fluctuations caused by that change. This may vary on
compiler, compiler version, code around your change, and test cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160316/dba0057c/attachment.html>

??> Agreed. Unless your code changes algorithm, you don't need to worry
too much about performance fluctuations caused by that change. This may vary on
compiler, compiler > version, code around your change, and test cases.

3% is a quite visible difference. I guess that testing was performed using
single compiler, hardware and so on. Why that change is observed ? Was it an 3%
fluctuation ?

?

Best regards,
George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160316/f274013d/attachment.html>

On 16 March 2016 at 09:26, George Rimar <grimar at accesssoftek.com>
wrote:
>> Agreed. Unless your code changes algorithm, you don't need to worry
too
>> much about performance fluctuations caused by that change. This may
vary on
>> compiler, compiler > version, code around your change, and test
cases.
>
>
> 3% is a quite visible difference. I guess that testing was performed using
> single compiler, hardware and so on. Why that change is observed ? Was it
an
> 3% fluctuation ?
I think it is just because the continue is really uncommon, but I
haven't actually profiled it. That is, I run "perf stat", not
"perf
record".

Cheers,
Rafael