[PATCH] D56942: Change TPI Bucket size for PDBs from minimum to maximum

[C.J. Hebert via Phabricator via llvm-commits]

CJHebert added a comment.

> 1. Can we do an adaptative scheme, based on `TypeHashes.size()`? Some of us have lots of DLL loaded in the process, this might uselessly increase the debugger's memory usage.

I don't know the answer to this one directly. This is the value that the MSVC toolchain appears to use for all PDBs, and is the default used in the microsoft-pdb github repo when making new PDBs. I have no particular knowledge, but from the repo I suspect that any other count supports old PDBs that may have used an adaptive algorithm like you mention.

> 2. Is `MaxTpiHashBuckets - 1` (why not `MaxTpiHashBuckets` rather?) really a hard limit, or would VS support higher values?

This constant comes from the Microsoft-PDB github repo and appears to be the cap for these streams. The check for MaxTpiHashBuckets is checked via count < MaxTpiHashBuckets in LLVM and cchnMax in microsoft-pdb, so subtracting one produces the largest count without violating this check. I don't know how pdbs with higher values would work with existing tools.

>> For context, this took the time for cold symbol look up for chrome.pdb from 10 minutes down to 2 minutes.
> 
> 3. What takes 2 min? For the VS debugger to lookup a symbol when you debug break?

The specific scenario that is improved was cold lookup of symbols when using the dx command in windbg. This command and Visual Studio watch window use natvis, which appears to cause recursively cause symbol look ups. The mentioned chrome.pdb is absolutely massive at 1.4 gigs, the behavior for smaller pdbs was also improved.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56942/new/

https://reviews.llvm.org/D56942