Multicore JIT MAX_METHODS = 0x4000 limitation

[FixBo]

Such limit looks to small now days

runtime/src/coreclr/vm/multicorejitimpl.h

Line 36 in c4792a2

const unsigned MAX_METHODS = 0x4000; // Maximum allowed number of methods (2^14 values) (in principle this is also limited by "unsigned short" counters)

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[mangod9]

Hey @FixBo, do you have a specific scenario where you are hitting these limits?

[FixBo]

I work at DevExpress and look for ways to speed up the startup of desktop applications for our customers. While multicore jit is a very nice feature, we have reached its limit with our components on large forms.

[EgorBo]

I work at DevExpress and look for ways to speed up the startup of desktop applications for our customers. While multicore jit is a very nice feature, we have reached its limit with our components on large forms.

I am just curious - does MulticoreJIT lead to a better startup compared to PublishReadyToRun=true ?

[FixBo]

does MulticoreJIT lead to a better startup compared to PublishReadyToRun

Almost the same. In combination with r2r it is slightly better.
2.4s clean. 1.4s r2r or MulticoreJIT (with higer limit). 1.2s with both.

[dennis-garavsky]

@EgorBo below is additional information on how this minor change can help empower dozens of thousands of DevExpress .NET Core customers (WinForms, WPF, Reporting, Dashboard, etc.) and likely customers of competitors (other UI component vendors on the market) to accomplish more:

1. Speed up effect greatly depends on the app and form complexity: the more complex the form, the better the results. Example 1: a complex report designer form with ribbons, property grid, toolbox, drag-n-drop surface, etc. - 2.5 sec (original), 1.5 sec (R2R), 2 sec (old limit, 1.5 sec (new patched limit), 1.3 sec (both R2R and new patched limit); Example 2. An Outlook-inspired demo with typical navigation panel, ribbon, list and detail forms, etc. - 5.5 sec (old limit), 3.5 sec (new patched limit), which is a 36% enhancement. Our customers create typical LOB apps (ERP, CRM, etc.), which are a way more complex in nature, and I saw startup times up to 35 sec for them with .NET Core. While .NET Core still cannot beat .NET Framework's ngen in performance (for example, the last demo opens in 2.2 sec with ngen), this little change will help us and thousands of our and competitor customers dramatically.
2. Our use-case scenario involves shipping hundreds of demo apps (WinForms, WPF, ASP.NET, .NET MAUI, etc.) to customers to try for evaluation and learning purposes. These demos are included into the DevExpress installer, which weights about 500 MB now. We cannot use R2R to speed up our .NET Core demos, because R2R will triple the distribution size (yes, we tested that), and it is also must be done in some sophisticated way on the client machine during the installation, because it is specific to the platform and runtime. Of course, this will also increase the installation time, which ruins the installation UX. I hope it is clearer now.
3. Microsoft also has the same goals for converting users to modern .NET from .NET Framework, better application startup is critical for user confidence and buy-in effect. We have already been working closely with @merriemcgaw and @Shyam-Gupta earlier this year on improving the WinForms designer performance for DevExpress components, so we hope this will be another successful cooperation too.
4. My colleague @FixBo just gave one of dozens cases he tested with the coreclr.dll he patched for 8.0.8. He has been testing this patched coreclr.dll extensively for the last week on our build farm with thousands of test cases, and his patch worked well so far. To give you an understanding of our Azure-based build farm scale, it is a six figure number per year.
5. This appears that this MAX_METHODS constant was designed 15 years ago for old software development requirements. Now we have more complex apps, also hybrid apps where WinForms/WPF/WinUI/MAUI can host native web view containers (BlazorWebView, HybridWebView), customers make heavy use of component vendors, and it is easy to hit 15-year old limits.

Please email me at dennis@devexpress.com if you require additional information on how this change will help us at DevExpress.

Cheers,
Dennis Garavsky
Principal Product Manager

[jkotas]

Fixed by #119359