<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 22, 2015 at 5:32 PM, 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>> Cool!<br>
><br>
> So the thin archive is a divergence from the standard ar file (although it's<br>
> compatible with GNU). Is there any room to push it further? Last time I ran<br>
> the linker with profiling enabled, it spends a good amount of time just to<br>
> find the terminating nul character in the archive file symbol table. If we<br>
> store string length for each symbol, the linker can read archive files<br>
> faster.<br>
<br>
</span>We can probably do it, yes.<br>
<br>
Take a look at the BSD format (used on OS X, I just implemented it in llvm).<br>
<br>
It is a bit better in that the symbol table is organized as a series<br>
of offset pairs. One to the member, one to the string table.<br>
<br>
This already improves handling on the traditional unix linker model<br>
where we scan each member to see if it should be included on the link.<br>
Once we find out it is to be included, it is really fast to scan past<br>
the member without looking for nulls as one has to do in the GNU<br>
format.<br>
<br>
That doesn't help with COFF were we do a single pass anyway, but there<br>
is more that we could benefit from the BSD format. I think that in<br>
practice the string table in in order, so that we can compute the<br>
string size by looking at the next member. I will give that a try.<br></blockquote><div><br></div><div>Even if the string table is in in-order in practice, you have to search for NUL characters byte-by-byte unless it's really guaranteed to be in-order, no?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another reason to come up with a thin BSD format variant :-)<br>
<br>
Cheers,<br>
Rafael<br>
<br>
P.S.: While testing the thin archive format I noticed that the thin<br>
.lib files were a lot bigger than what I was getting on linux. It<br>
turns out it was because cl.exe was producing .obj files with a *lot*<br>
more symbols than clang on linux. Trying clang on windows showed that<br>
cl.exe was not dropping what we call linkonce_odr, but clang on<br>
windows still produces more symbols than clang on linux.<br>
</blockquote></div><br></div></div>