ReadyToRun images are not as efficient for .NET Core 3 as NGen for .NET Framework

[AlexChuev]

• .NET Core Version: 3.0 Preview 8
• Windows version: 1809
• Does the bug reproduce also in WPF for .NET Framework 4.8?: No
• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? No

Problem description:
Since Ngen.exe and Native Image Task are not available in .NET Core 3, ReadyToRun images are the only way to reduce the application startup time and avoid delays caused by JIT compilation. However, our tests show that for the same WPF application that initializes three times faster after using Ngen.exe, ReadyToRun images provide the difference of only 25%.
This is a huge hit for our users, since with many libraries and theme resources, JIT compilation is one of the main factors affecting load times. For some real-life applications, the use of Ngen.exe allowed our users to shave up to 6 seconds (half) off the initial start time.

Minimal repro:
You can find samples for .NET Core 3 and .NET Framework here: https://github.com/AlexChuev/ReadyToRunPerformanceTest
These samples use DevExpress WPF assemblies to demonstrate how Ngen.exe and ReadyToRun images affect projects with many classes and theme resources. If you need published apps or other samples for your tests, please let me know.

P.S. I'm posting this in the WPF repo because the difference between Ngen.exe and ReadyToRun images highly affects WPF applications. Normally, the JIT compiler processes classes and methods only when they are needed for the program execution. However, when WPF loads theme resources for a control, this causes all classes referenced in these resources (including classes referenced in currently unused or invisible parts) to be processed by the JIT compiler. In addition, static constructors of many WPF classes contain the DependencyProperty registration code that may cause even more classes and methods to be JITted.

[rladuca]

@fadimounir Where should we file a companion bug on .NET?

[fadimounir]

@rladuca Sure you can file a companion bug on dotnet/coreclr. We'd be interested in diagnosing this more, although one thing to keep in mind is that R2R by design principle will always be a bit slower than fragile native images, because they are version resilient (they do not have the same fragility as old ngen images).

If you need published apps or other samples for your tests, please let me know.

@AlexChuev That would be very helpful

cc @jkotas FYI

[grubioe]

New CoreCLR issue created, keeping open in WPF repo for tracking purposes.

[lindexi]

The other startup performance:

[ekalchev]

Please look at this issue. It basically negates all performance benefits from .net core for desktop apps making it slower than .net framework. We are currently migrating .net framework WPF app to .net core and we were unpleasantly surprised that it got slower startup times. This issue affect the entire class of desktop application.

The main issue we see is the JIT times. It seems NGEN 20 years old technology is 3 times better eliminating JIT than Ready2Run. Unbelievable.

[lindexi]

Should we modified the milestones from 7.0 to 9.0?

[pchaurasia14]

@lindexi - This one would require some in-depth investigations at our end and I don't think we'll be able to address this for .NET 9. I'm marking this to future release for now and will change it to .NET 9 if we can get to this sooner.