What if OSR and PGO were to have persistence option?

[maxima120]

Talking about OSR and PGO explained here: https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7

I was concerned with instrumentation overhead for tiered compilation since I heard about it..

Imagine a production server app optimised for performance. And then there are some counters being counted and some decisions being made etc.

Although I do accept that general idea of optimising running code based on observation is invaluable feature.

My idea is (having that server app in mind) - what if

instead of small but permanent overhead for instrumentation and constant monitoring and attempts to optimise etc

there were a mechanism that has larger overhead for very limited period of time but then no overhead for the rest of app life-time

for example 1) enable instrumentation for a week; 2) collect information in prod in real life usage scenarios; 3) store that "profile" 4) make exe image without instrumentation and optimised by loading the "profile"; 5) repeat in few months

Obviously this wont benefit every application. However majority of server apps I came across were pretty homogeneous in how they are used and this would change slowly with time. As slow as seasonal variations during the year..

Also as a pro argument - this way .NET devs will be less constrained as performance overhead can be sacrificed a bit during data gathering periods. so they might come up with more and better ways to optimise further.

[hez2010]

It is already possible with the static pgo tool and crossgen2:
You can collect the profile information and save it to a mibc file (dotnet-pgo tool), then recompile your app with crossgen2 (ReadyToRun) using the generated mibc file.

See https://github.com/dotnet/runtime/blob/main/docs/design/features/dotnet-pgo.md for document.