Consider adding mibc/profile for R2R FSC/FSI for faster startup

We should consider adding both managed and native mibc/profiles for fsc and fsi:

• Come up with both FSC and FSI scenarios for profile generation, add them to dotnet-optimization (@EgorBo can assist with that):
  • Scenarios for collecting the profiling data (F# console, or web app, for example) which will be used to produce profiles.
  • Profiles then will be packaged and published as a NuGet package.
• When we building the compiler, download the NuGet package with profiles, and use them when building R2R compiler.

@EgorBo Have I missed anything?

[EgorBo]

PR: https://dev.azure.com/dnceng/internal/_git/dotnet-optimization/pullrequest/25175

I played with the resulting MIBC locally - it doesn’t give much, but it works good with R2RComposite, e.g. I was measuring how long it takes to build https://github.com/giraffe-fsharp/Giraffe

for(;;) { Measure-Command { C:\prj\fsharp\artifacts\bin\fsc\Release\net7.0\win-x64\publish\fsc.exe "@girafe.rsp" }}

best results:

Default: 5350ms
PublishReadyToRun for fsc: 4184ms
PublishReadyToRun + Composite: 3589ms

Around 30% improvement! 🙂

also, hit a runtime issue while I was collecting MIBC: https://github.com/dotnet/runtime/issues/74295

[EgorBo]

We will also need to understand how does it affect, .tail calls, for example, since F# emits a bunch of them.

We used to avoid instrumenting methods with explicit tails calls but then decided to allow it - https://github.com/dotnet/runtime/pull/58632 so should be fine