Performance profiling for WebAssembly

[SteveSandersonMS]

Net 10 goals - single threaded Event Pipe and Diagnostic server

• gc heap dump, counters, CPU sampling
• implement single-threaded DS native code
  • [browser] single threaded diagnostic server #111910
• single threaded managed AggregationManager and EventPipeEventDispatcher
  • [browser] managed Diagnostics.Metrics and Diagnostics.Tracing single-threaded #113524
• implement single-threaded sample profiler (interp, AOT, jiterp)
  • for browser dev tools [browser] samplepoint instrumentation into Mono profiler #112352
  • for EP [browser] EventPipe - CPU sampling - single thread #113758
• implement JavaScript API for triggering trace
  • [browser] add and load empty ES6 module dotnet.diag.js when FeaturePerfTracing #112787
  • [browser] event pipe - JavaScript part #110818
• implement WebSocket transport for EP
• Documentation [Pre4] Performance profiling for Blazor WebAssembly apps AspNetCore.Docs#35230
• trigger re-build with <WasmPerfTracing /> change
• fix timeouts in ds-router for WebSockets [dsrouter] fix web socket startup diagnostics#5121
• WBT and manual tests [browser] EP testing #114232

Net 10 nice to have

• include ds-router in the dev-server, so that the IPC channel is visible on the local machine
• explore how .nettrace output could be used for PGO AOT in Mono
  • [mono] Profiled AOT - PGO tracking  #69512
• click thru symbols in the trace to C# code in VS
• optimize sampling profiler
• simplify browser <WasmProfilers>browser</WasmProfilers> and config.browserProfilerOptions
• Timing-Allow-Origin in the devtools

Future goals

• propagate from the WASM client to the server side open telemetry
• integration with VS or VS code
• make multi-threaded event pipe also work
• annotate Mono AOT with event pipe events
  • FRAME_TYPE_IL_STATE
• annotate AOT/Interp transitions
• annotate JS interop with event pipe events
• use stats about Interp of runtime libraries to bring more intrinsic methods to Interp
• propagate event pipe events as performance.mark() and performance.measure()
  • optional, configurable
  • HTTP header Timing-Allow-Origin
• propagate browser events as event pipe events
• Add a way for JavaScript to push events to EventSources.
• VS integration
• Refactor runtime startup to allow the diagnostic server to async pause the browser thread.

Non-goals

• (debugging of) full memory dump - the layout of WASM linear memory is significantly different from other OSs. Also it doesn't capture WASM stack trace, just shadow stack.
• DS/EP and Mono profilers at the same time
• Anything based on DiagnosticCounter like RuntimeEventSource and CounterGroup, keep UnsupportedOSPlatform("browser")

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Stamo-Gochev]

@SteveSandersonMS Can you share more information where this profiler can be found? I see that it is internal, but I can try to rebuild the source code on my side to expose it in some way as I want to debug a wasm app for performance reasons. I have no expectations for it to be working as you mentioned it is targeting 6.0 or later, but I can give it a try for testing purposes.

[Stamo-Gochev]

@SteveSandersonMS Any updates?

[SteveSandersonMS]

The experimental code we used is in https://github.com/dotnet/runtime/tree/stevesa/hierarchical-profile, however it's not intended for external use, hence there's no information about how to build or use it, or how to understand any data it collects, and it most likely no longer works with current builds of the runtime.

[szalapski]

Would like to see a way to profile Blazor on the client, with an eye toward optimizing performance. Main scenario: I just clicked on an item and it worked 20 seconds before I can see the new UI, and I am quite certain it is not due to download time/network latency; what's taking so long that I should try to optimize?

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[jirisykora83]

@SteveSandersonMS Any updates?

[jirisykora83]

Would like to see a way to profile Blazor on the client, with an eye toward optimizing performance. Main scenario: I just clicked on an item and it worked 20 seconds before I could see the new UI, and I am quite certain it is not due to download time/network latency; what's taking so long that I should try to optimize?

I face similar issue and one workround is create BaseComponent add it to _Imports.razor as base class for every component @inherits XXX.BaseComponent and then use component live cycle with https://developer.mozilla.org/en-US/docs/Web/API/console/time this give me at least some insight.

This is inspired by https://remibou.github.io/Profiling-in-Blazor/

console.time produce some sort of flamegraph in chrome. This is nowhere near the dev experience with full .NET profiler of course.

[MertUssakliMSFT]

If there was at least a way to relate compiled wasm-functionss you see in the Edge profiler back to .NET code symbols, that would be a huge step forward! I can profile and see CPU-heavy workload causing UI delays, but it is impossible to debug it back to what part of the code would need optimization.

[Chris-D-Turk]

@MertUssakliMSFT you can actually see the real method-names if you enable AOT compilation in your csproj:

    <RunAOTCompilation>true</RunAOTCompilation>
    <RunAOTCompilationAfterBuild>true</RunAOTCompilationAfterBuild>
    <WasmNativeStrip>false</WasmNativeStrip>

But the build takes a very long time with this config - ~10min for a new blazor wasm solution on my machine.
Maybe you can speed up the build, if your strip unused assemblies - but I don't know how to do this.

[MertUssakliMSFT]

@Chris-D-Turk, cool tip -- will keep this in mind the next time I need to do perf profiling.

Does it work in Release/Ship as well as Debug?