[dotnet-trace] Update Convert and Report to handle Universal.Events

[mdh1418]

Fixes #5610

Demonstrates using the updated ThreadTimeStackComputer in TraceEvent 3.1.28 to generate ThreadTime stacks from traces containing Universal.Events.

This PR does the following:

• Updates TraceEvent to 3.1.28 (including System.Text.Json and System.Text.Encodings.Web dependencies)
• Moves trace-to-stack generation to shared location for Convert and Report
• Removes GeneratePathProperty which was only consumed by Remove file-dedup workaround #2233

Before

dotnet-trace.exe convert .\trace.nettrace --format Speedscope

{"exporter": "[email protected]", "name": "trace.speedscope", "activeProfileIndex": 0, "$schema": "https://www.speedscope.app/file-format-schema.json", "shared": { "frames": [ ] }, "profiles": [ ] }

dotnet-trace.exe report .\trace.nettrace topN -n 10
Top 10 Functions (Exclusive)                                                  Inclusive           Exclusive
1.  EventName: Universal.Events/cswitch                                       98.08%              98.08%
2.  EventName: Universal.Events/cpu                                           1.92%               1.92%
3.  EventData: Value=0x00066328                                               0%                  0%
4.  EventData: Value=0x000d208c                                               0%                  0%
5.  EventData: Value=0x000de56c                                               0%                  0%
6.  EventData: Value=0x0006b530                                               0%                  0%
7.  EventData: Value=0x00075490                                               0%                  0%
8.  EventData: Value=0x001038bc                                               0%                  0%
9.  EventData: Value=0x00064e10                                               0%                  0%
10. EventData: Value=0x000ee868                                               0%                  0%

After

dotnet-trace.exe convert .\trace.nettrace --format Speedscope

dotnet-trace.exe report .\trace.nettrace topN -n 10
Top 10 Functions (Exclusive)                                                  Inclusive           Exclusive
1.  BLOCKED_TIME                                                              92.4%               92.4%
2.  vmlinux!schedule                                                          115.47%             26.1%
3.  usereventstest!Program+<>c__DisplayClass6_0::<ManagedWorker>b__0(objec    -5.76%              -5.73%
4.  libcoreclr.so!?                                                           46.74%              -1.68%
5.  vmlinux!_raw_spin_unlock_irqrestore                                       -0.97%              -0.97%
6.  vmlinux!get_futex_key                                                     -0.96%              -0.96%
7.  libclrjit.so!?                                                            -0.96%              -0.92%
8.  vmlinux!copyin                                                            -0.9%               -0.9%
9.  node!?                                                                    -0.9%               -0.7%
10. libc.so.6!epoll_pwait                                                     13.48%              -0.5%

[mdh1418]

Still need to figure out how to resolve symbols from the nettrace like how PerfView does.

[noahfalk]

The inclusive/exclusive numbers having values less than zero or greater than 100 also seems very fishy :)

[brianrob]

I LOVE that you're doing this. I've seen a lot of people use these features successfully, and having them work for collect-linux (one-collect) traces will be a great addition. A couple of comments below.

[brianrob]

I think you will want to separate a bit of the configuration based on whether or not the trace comes from the runtime (EventPipe) vs. one-collect. Traces from one-collect are going to have multiple processes and then either CPU time or Thread time.

One of the great things about this view is that when the data is focused on the right target (usually just a single process), it can be very useful. In the current state, we're looking at all processes on the machine, and blocked time. Blocked time almost always dominates CPU time because it's not a consumable resource - it's the time that was spent by every thread when they were blocked.

I'd recommend the following:

• Filter to just CPU time - don't show blocked time in these tools.
• Provide a way for users to select the process they want to filter to.

[brianrob]

For symbol resolution, here is the current state in PerfView/TraceEvent:

• Native code: Symbols must be present on the collection machine at collection time so that one-collect can pick them up. They show up in the trace as ProcessSymbol events. From what I can see you're already getting these resolved properly.
• Jitted Code: Symbols are emitted into the trace as ProcessSymbol events.
• R2R Code: PerfView/TraceEvent downloads these from the symbol server at analysis time via an instance of SymbolReader.