Mapping symbol formats back to the original code

[nschuessler]

I have a need to map profiling data back to the original code to provide tips in the IDE.
The reason is that even if you have a central team collecting and displaying this data in a tool somewhere, few developers actually will go to that tool on their own to review it.

Having it right in the IDE while they are working would allow more people to see methods that have performance issues.

Here are some example symbols collected from PerfView traces:

mscorlib!System.Collections.Generic.List`1[System.__Canon]..ctor(System.Collections.Generic.IEnumerable`1<System.__Canon>)
system.core!System.Linq.Enumerable+<TakeIterator>d__25`1[System.__Canon].MoveNext()

Note that these symbol names cannot be generated using built in Roslyn formatting capabilities. So the first approach people would try would be to write a bunch of regular expressions to map roslyn metadata format -> symbol format or more likely to "normalize" the symbol format -> how these methods are known in the IDE.

Of course there are a number of ways to do this, all with limitations:

1. Normalizing in the forward or reverse direction as mentioned above
2. Developers could tag methods with an attribute containing an identifier (e.g. GUID) that doesn't change, and the guid could somehow be propagated to the ETW traces for matching
3. The compiler could generate a GUID and a feature could be added to output a mapping from GUID => original name => symbol name. If the ETW traces had the GUID, in theory you could map backwards.

For the normalizing (1) case:

• The downside is it is quite tedious to manually maintain this mapping and keep them in sync. The best scenario here is that this mapping is done by a library built in the roslyn repository that will break the build if a new symbol format is created w/o a reverse mapping rule being added.

for (2) and (3) downsides:

• Even if we can generate a mapping file as compiler output, the GUIDs or method ids would not be the same from build to build. Often you don't know what build the profiling data came from and the source code may differ slightly.

for (2) the additional downside is that manually putting attributes on each method is tedious. Tools are supposed to make things easier, not add work on your plate.

The other benefit of being able to reverse map these symbols is that fixes can be automated. I.e. if you see List``1.Add allocating lots of memory, a roslyn fix provider could go and find where the List<T> is constructed and add an estimated size.

Any thoughts or tips on how we can get tooling and automation to be able to correlate the data from production with the code in the IDE?

[ryzngard]

There hasn't been much traction here, but I would suggest one thing: If you're using ETW for tracing, tools for ETW events have support for mapping symbols. WPA supports this https://docs.microsoft.com/en-us/previous-versions/windows/desktop/xperf/symbol-support

If you can map the traces to a symbol in a similar way, that would be ideal. It would use actual symbol information and doesn't need to do any new logic that might be error prone.