<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 20, 2015 at 1:36 PM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.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="">>>That would be awesome. Please be careful about the detail conditions because the symbol resolution performance is affected by various conditions such as library search order, symbol name, etc. Probably the easiest way to evaluate that is to use a real world program, such as Clang, as a benchmark.<br>
><br>
>What about that synthetic case: 1 DSO with N generated functions and 1 caller file with N * 2 calls to this different N functions.<br>
>Comparing time of first N calls and second N calls we can know the time of N dynamic resolvings and time of clear N calls since PLT table will be filled with actual addresses after first N calls.<br>
><br>
>That test may be good to measure the bare performance, but I guess that's synthetic. One of the big selling points of lazy binding is that it would reduce the number of symbol resolution because not all function are actually used.<br>
<br>
</span>Ok. So as using clang do you mean to build something ? What about compare time of self-hosting with and w/o lazy code then ?<br>
</blockquote></div><br></div><div class="gmail_extra">That I don't know. My wild guess is compiling something is too large as a task that that would hide the effect of lazy binding, but I'd have to try.</div></div>