<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 10, 2016 at 4:36 AM, 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 class="">On 9 March 2016 at 23:51, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> I think this is towards a good direction, but I want to understand what is<br>
> going on more as 9% slowdown is somewhat significant.<br>
><br>
> On Wed, Mar 9, 2016 at 7:11 PM, Rafael Espíndola<br>
> <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>><br>
>> OK, looking at perf, what I got was that the "slow" instructions were<br>
>><br>
>><br>
>> mov    (%rcx,%rax,8),%rax<br>
>> mov    0x28(%rax),%rax<br>
>> mov    (%rax),%r13<br>
>><br>
>> Which correspond to:<br>
>>  * given a symbol index, get the SymbolBody*<br>
>>  * get the backref<br>
>>  * get the repl<br>
>><br>
>> I think these are only slow because we then proceed to use the data<br>
>> and pref blames the instruction that is computing the dependency of an<br>
>> expensive computations.<br>
><br>
><br>
> Unless added to the symbol table, SymbolBodies does not have backrefs. Their<br>
> backrefs are nullptrs. So I think for local symbols, that code would not be<br>
> executed. Is this actually a bottleneck for local symbols?<br>
<br>
</span>But it still returns itself as a repl. So a hot code path went from<br>
checking a value with null to checking a field of the returned pointer<br>
(Body.isLocal()).<br></blockquote><div><br></div><div>I expect that after this change, we will be removing many isLocal() function calls because in many places we will be able to handle local and global symbols in the same way (because they will be represented in the same data structure.) Does this affect the performance? </div></div></div></div>