PGO vs AOT, which should I use?

[alexandrehtrb]

Hello,

I read the blog post on Performance Improvements in .NET 7 and I am trying to better understand PGO and AOT.

From what I understood, in broad lines:

• PGO means a slower startup, but after some execution time, the program self-tunes itself and the performance increases.
• AOT means a faster startup and smaller programs.
• They are a little incompatible with each other, because PGO works on intermediate language and AOT compiles some of the code into low-level code.

Is that it?
When should I prefer one instead of the other?

[EgorBo]

PGO means a slower startup, but after some execution time, the program self-tunes itself and the performance increases.

Correct, it's a bit slower to start because of instrumentation in Tier0. We try to minimize that effect in .NET 8.0 e.g. via #70941 where we will be instrumenting only hot tier0 code. Also, we try to reduce overhead from instrumentation in general or/and enable some quick opts in tier0.

In .NET 6.0-7.0, for better effect from PGO you need to disable R2R via DOTNET_ReadyToRun=0 so all the code executed on start will have to jitted from scratch - it affects start time badly

AOT means a faster startup and smaller programs.

Depends on what kind of AOT you mean, if it's NativeAOT then yes - fast start, small app, no self-tunning.
In case of R2R (PublishReadyToRun) we'll be able to re-JIT hot AOT'd code in .NET 8.0 (again, #70941) so we still will have fast start up and self-tunning.

So In .NET 7.0 and older I'd say use NativeAOT or R2R everywhere where start time matters and enable PGO if you need better stable-state performance.