Add mibc/profile for R2R FSC/FSI for faster startup

[vzarytovskii]

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]

Native profile is less relevant here, although, it might uncover some scenarios we don't hit often when we run C# programs and optimize them inside JIT/VM/GC.

I assume the primary target here is to make FSC compiler faster - for that we need a scenario from you where FSC compiles a program so then we can run that scenario on our pipeline, generate an mibc and publish it to a nuget so you can just download it and use during "dotnet publish" for FSC (ideally, with CompositeR2R mode)

[vzarytovskii]

Native profile is less relevant here, although, it might uncover some scenarios we don't hit often when we run C# programs and optimize them inside JIT/VM/GC.

Got it, thanks.

I assume the primary target here is to make FSC compiler faster - for that we need a scenario from you where FSC compiles a program so then we can run that scenario on our pipeline, generate an mibc and publish it to a nuget so you can just download it and use during "dotnet publish" for FSC (ideally, with CompositeR2R mode)

Yes, faster startup times for compiler, and, most importantly, interactive (FSI) are what we're after.

[vzarytovskii]

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

[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

[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