<div dir="ltr"><div>On Fri, Mar 20, 2015 at 3:23 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20 March 2015 at 18:08, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> Newly-added undefined symbols may be solved by other file in the same<br>
> archive, so you've got to restart scanning from beginning. You would visit<br>
> the same symbol many times. Is that faster?<br>
><br>
<br>
</span>I don't expect many passes in practice.<br></blockquote><div><br></div><div>I still think we need at least two passes if a symbol is resolved using a member file (first iteration resolves the symbol, and the second iteration is to make sure that no more symbols can be resolved using the archive file.) Two passes is many compared to hash table lookup, no?</div><div><br></div><div>It may worth to mention that the hash table construction is paralellized. We create a hash table for each archive file in parallel because there's no dependency between them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You can also avoid looking at the symbols of members you already<br>
added. To do that you would need to keep just a table of indexes or<br>
"double buffer" the list: at each pass either a member is added or the<br>
symbol pointers are added to the other buffer. At the end of the pass,<br>
swap the buffer.<br>
<br>
You can also save the hash computation.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>