Add console runner for measuring Blazor perf on desktop interpreter #24469
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the runner I've been using for capturing profiling data for rendering scenarios. It takes our existing benchmark scenarios (well, just the grid ones so far) and exposes them as a standalone console app that runs without involving any browser. It's just doing the .NET side of things, and discarding the resulting renderbatches since there's no DOM to apply them to. You can run this under different .NET runtimes to compare the execution times.
I've been running this under the Mono desktop interpreter, with the interpreter modified to capture instruction counts when we enter and exit methods. This produces a profile trace that can be loaded into Chromium's profile inspector UI. As a separate work item, we should talk about whether we could make this trace-capturing feature be built into the Mono interpreter for reals, possibly even working when running under webassembly. One tricky aspect of this is being confident that it won't worsen actual perf, since even an
if (profilingIsEnabled)
check might have an impact if we do it on every single method entry/exit, so if this is too problematic we might want to consider having a separate "profile enabled" build of the runtime. Maybe there's some fancier way to avoid the overhead when profiling isn't enabled, but that's all separate to this PR.Even if the Mono interpreter never gets built-in a profile capture feature, this PR is still very useful because it makes it much simpler to use standard CoreCLR profiling tools or to compare Mono interpreter vs a JIT-capable runtime.