FSC: Consider enabling background JIT with non-dynamic PGO for faster compilation

Context

I noticed that JIT takes a considerable amount of time in compilation, and the fraction of time it takes is especially high for small projects.

I experimented with using non-dynamic PGO for JITting to allow JITting to happen in the background, before its results are needed.

Tests

I tested it against an empty project from the dotnet template (just one file). The PGO-enabled compilation was ~300ms faster (~0.95s -> ~0.65s). I generated the profile by running compilation on the same test project a few times, and measured timings then.

Here is a profile showing JIT work happening without PGO: It shows 1200ms of JIT on the main thread, and similar amount on other threads (mostly blocking actual work).

Here is a profile showing JIT work happening with PGO: It shows 835ms of JIT on the main thread, ~700ms on other work threads, and 1250ms on a dedicated JITting thread (CLR worker).

Questions

• Am I missing something? Is non-dynamic PGO being used already somehow?
• Are there any major drawbacks to using this?
• If enabled, how would the profile be deployed/generated on the end-user’s machine? Would hiding it behind a feature flag/env variable make sense?
• Can SDK ship no profile and let the user’s first build generate one? We could use profile names based on the name of the project being compiled. This means no deployment changes are needed, and it can be fully controlled by the enduser
• I know dynamic PGO exists in NET6, but I don’t think that’s needed for the compilation process.
• I’m aware background compiler service might become a reality at some point, making JIT irrelevant, but this solution seems so cheap that it should be worth considering anyway.

[jkotas]

I know very little about it and how well tested it is maybe @jkotas knows better?

Multicore JIT is supported feature. If you run into functional problems with it, we will investigate them. It is used by Powershell.

[vzarytovskii]

The flag I tested is 3 lines of code and requires no changes in the deployment.

It only looks like it 😃 We need to make changes to several places, including (probably) our signed build (both SDK and VS), dotnet/dotnet, source build, maybe something else (because we don’t “maintain” flags for publishing).

MIBC might be the easiest solution here (I have added almost everything which is needed, so it’s already in progress).