[PATCH] D51887: lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence.

[Nico Weber via Phabricator via llvm-commits]

thakis added a comment.

In https://reviews.llvm.org/D51887#1232119, @zturner wrote:

> In https://reviews.llvm.org/D51887#1231332, @thakis wrote:
>
> > Did some measurements on my linux box (didn't have access to my win box). There, just naively calling xxHash64 on the 1.4GB chrome.dll.pdb file after creating it, doing the parallel xxHas64 computation, this patch, and the old nondeterministic guid code all take about the same amount of time (around 32s, min-of-4 links with each approach is within 0.2s of that). I'll try this on Windows tomorrow.
> >
> > (Naive: https://reviews.llvm.org/D51956 Parallel: https://reviews.llvm.org/D51957)
>
>
> I'm a little surprised it's this fast.  Are you sure it's even doing anything?  What kind of hard drive are you using?  A SATA III bus interface, which is still probably the single most common interface used by SSDs, has a theoretical maximum transfer rate of 600MB/s, so you'd be adding at least 2.5 seconds to the link, and that's under optimal circumstances.  A SATA II interface, which is also still common enough, is 300MB/s.  nVME and PCIe interfaces can reach gigabytes / second but we definitely shoudln't be basing measurements off of those.  I don't really have a super strong opinion, but it's something to think about.


I'm surprised too. I did check that the guid in the pdb was computed by the new algorithm though, and that the "size" var in front of the xxhash64 call contains 1.4GB. The linux disk cache is pretty good though, so I'm guessing it was all in memory. I'm doing Windows next, where I expect the disk cache to be worse.


https://reviews.llvm.org/D51887