Why Roslyn doesn't inline IL directly instead of putting pressure on JIT for known call sites in release mode?

[ackava]

To improve faster loading time, can't Roslyn inline IL directly instead of postponing inline on JIT? I am only talking about some methods that are clearly marked as [AgreesiveInlining], or some methods that are very small.

I see JIT performing inlining correctly, but what is the idea behind not doing IL inlining at compile time?

I agree that the assembly size will increase, but will it not reduce JIT time?

Most of the startup time is eaten by 30-40% only in JIT.

[huoyaoyuan]

Roslyn doesn't know the IL of any called method at all when it comes from another assembly. It may not exist at all (using ref assembly), or being replaced at runtime (version upgrading of dependency)

I agree that the assembly size will increase, but will it not reduce JIT time?

It has a risk to regress JIT performance. Larger method body requires longer time to be compiled in a whole. Moreover, if a callee is inlined twice or more times, it will be compiled for more times.

Most of the startup time is eaten by 30-40% only in JIT.

ReadyToRun is expected to take the place here.

[ackava]

I am talking about inlining methods of same assembly, shouldn't this reduce the jit time? Optimizing at compile time should be beneficial.

[huoyaoyuan]

I am talking about inlining methods of same assembly, shouldn't this reduce the jit time?

No, it's mostly a regression for startup, because inlining doesn't happen in Tier 0.

C# tends to preserve the program structure as-is as a flavor. F# does pre-IL inlining.

[ackava]

C# tends to preserve the program structure as-is as a flavor. F# does pre-IL inlining.

I think developer should have a choice to test whether inlining at time of compilation is worth or not, if F# can, even C# can.

[huoyaoyuan]

developer should have a choice

if F# can, even C# can.

It affects language design heavily. The language needs to specify what can be inlined, and its behavior. C# isn't designed in allowing that.

[tannergooding]

The developer is also often a terrible judge over what is or isn’t beneficial to inline and often cannot correctly make decisions based on the nuance of the target hardware they will actually run on. — The developer will often try to make decisions based on non-representative micro benchmarks that actually make code slower. Enough so that native compilers tend to not respect their inlining attributes in all cases either and may even have an “outlining” phase (particularly if pgo data is present) to undo user inlining.

The JIT/AOT compiler has the relevant context and does the appropriate optimizations already.

It is far more meaningful to try and identify places where the JIT/AOT is not doing what you’d like and logging issues, with appropriate real world benchmarks, to have those scenarios fixed instead.