microsoft / microsoft/perfview
NGEN PDBs end up in symbol cache
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 4.7k
- Forks
- 775
- Avg merge
- 5d 11h
- Merged PRs (30d)
- 9
Description
We analyze zipped ETL trace files which contain included NGEN pdbs in an automated pipeline. In order to give the location info of those NGEN pdbs to SymbolReader we use the source server style syntax of
SRV*<potential cache path>*<on file root of PDB extraction>
Since the PDBs are stored in the zip in a source server like directory structure, and we maintain that structure when we extract them, TraceEvent can locate them treating our local extraction root as if it were a source server (i.e. the path it would construct to do a source server lookup is the same path it needs to locate them on disk).
This is fine and well except it means it does the following for NGEN PDBs
- Locates them on disk (good)
- 'Downloads' them (not great but ok), this seems to mean copying them to some temp file with the extension .new
- Copies them into our cache (bad)
- Ultimately loads them from the cache
Step 2 is unnecessary since the PDBs are already on local disk in a loadable location. Step 3 is bad because it means PDBs that only will ever be used for this one analysis, end up in our machine's persistent symbol cache which stores things like OS and CLR dlls, which do make sense to store in a shareable location to be used amongst all analysis runs.
I am not sure the best solution. It seems either:
-
An 'extension' of the SRV syntax, something like LOCALSRV that indicates it uses symbol server style directory layout BUT it exists on local disk so you can skip step 2 and 3 above.
-
An additional argument to symbol reader, so we have the normal symbol server where we get all the global cacheable symbols like the OS and CLR bits, then we have another argument like localNGENPdbPath or something that tells the root to look for on local disk.
Either would seem to work, so it seems like a design decision I'd leave up to you folks.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading SymbolReader's handling of the SRV syntax and its local lookup, temporary-file, and cache steps described in the issue. Decide how local NGEN PDB roots should be represented alongside normal symbol servers, then verify that extracted PDBs load from disk without entering the persistent cache while global symbols retain existing caching behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- devtools, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100