Dotnet uses crossgen2 to readytorun DLL to improve startup performance

I did a rigorous startup performance evaluation on several applications , The contrast is in .NET Framework and dotnet 6 Application startup performance under , As expected, we can see , On the user's device , After NGen After that .NET Framework It can provide very superior startup performance , Plus .NET Framework It is part of the system components , There are few cold starts , Most of DLL Are preheated in the system . Start up performance , Is still .NET Framework Than dotnet 6 Very fast . And in destroying .NET Framework Of the runtime framework layer NGen after , You can find .NET Framework The startup performance of is no better than dotnet 6 Start up performance . In order to be in dotnet 6 Bottom leveling .NET Framework Startup performance differences , Introduction and NGen Of the same rank ReadyToRun To improve the overall performance . This article will show you how to dotnet 6 In the application of , Use Crossgen2 Tools , to DLL Generate AOT data , Improve application startup performance

I expect this article to be time effective , Concepts are changing , This article is in 2022.05 Compiling . If you have been reading this article for too long , Please be careful that the outdated knowledge of this article misleads

Before the start , Please clarify the concept

stay dotnet Inside , These concepts are all changing , It hasn't been completely settled yet . Talking about dotnet Inside AOT Before , It is necessary to refute the rumor first . The first rumor is AOT It means better performance ？ It's not , use AOT It can reduce the application startup process , from IL Loss of conversion to native code , But through layered compilation (TieredCompilation) technology , This part of the difference will not be particularly large , Plus dotnet 6 introduce Of QuickJit technology , It can further narrow the gap . But even so , Start up performance , use AOT There are advantages , Because the startup process is performance sensitive , In addition, large projects will need to execute a lot of code logic during the startup process , Even if JIT Fast and dynamic PGO With the help of , Still, the performance is not as good as that of... Due to too much work AOT The way . because AOT It is production static logic , Take only the minimum set of platforms , And cannot JIT equally , Dynamic optimization according to the running equipment , This is why the performance during operation , stay JIT Get into Tier 2 The optimized performance is much better than AOT The way . let me put it another way , Use it all the way AOT Without adding any JIT Just improve startup performance , But it reduces the performance of the running process

If I start the performance, I will also , The performance of the running process also needs to be improved ？ This is ReadyToRun The concept of technology , stay DLL On the incoming call of , First use AOT technology , Part of the logic is run in advance JIT And the binary logic after running is also recorded in DLL Inside . In this way, when the method is called for the first time , Reduce JIT The part of , As far as possible before use AOT The content of , To improve application startup performance . And after the app runs , Still running JIT The optimization of the , In this way, the startup performance and the performance of the operation process can be considered

How to achieve ReadyToRun The concept ？ A few techniques and tools are needed , among Crossgen2 Is to ReadyToRun Tools for . adopt Crossgen2 Tools , It can be done to DLL Static AOT To incorporate into DLL Inside

But this approach is not without shortcomings , That's extra programming DLL Of AOT The content of , Will increase DLL Volume . and DLL The increase in size will reduce the performance of reading files during startup , Plus AOT and JIT Process switching also requires judgment logic , After adding this loss , Compare again QuickJit technology , In fact, we use Crossgen2 Conduct ReadyToRun Not for all DLL Can improve startup performance

To solve the above problems , stay dotnet In the PGO The concept of . The methods called in the startup process are limited , If you can know which methods the application startup process will call , Just use this part of the method AOT So right. DLL The effect of volume will be much smaller . This is it. PGO Problems to be solved , By introducing PGO The concept , During application operation , Understand what will happen during application startup IL Logic , Write down this logic , For guidance ReadyToRun The process goes on AOT What methods . So that AOT The process does not need to be for all IL Logic , Instead, only those needed in the application startup process can be used AOT The process . This can greatly improve the startup performance of the application . however PGO There is more to be done than ReadyToRun Guidance of , It can also be used as JIT In the process , Give Way JIT Learn what can be run in the background thread in advance IL Conversion to achieve higher startup performance . It must be noted that , I asked several big men and learned that , Current PGO Or a toy , Although the performance evaluation can achieve good results , However, it does not have the ability to use the release environment

about AOT Non decompilable refutation . As you can see above ReadyToRun technical , It is still reserved IL Logic , It's just DLL And then add AOT Generated binary data , Thus, the startup process is reduced JIT Loss of . That is, if ReadyToRun Technology , It can make the application faster （ Not necessarily faster ） Start up performance , At the same time, it also has the performance of the original operation process . But is it possible not to decompile , Nature can't do it , The original IL The code is still there , That is to say, adopt ReadyToRun technology , There is no additional protection capability . That's the second question , If pure AOT technology , Whether the code protection capability can be achieved ？ Um. , Can you add a little . If the coordination is confused , I think it's almost done . If you want to talk about anti cracking ability , Score two , One is 60 branch , One is 70 branch , Full score is 100 branch . I really want others not to understand , Just write some junk code , When I do my best , Make sure you don't even understand

Back to the topic , How to be in dotnet Inside through Crossgen2 Tool execution ReadyToRun Improve application performance ？ Don't be cheated by the authorities , If only csproj Or add it at the time of release ReadyToRun Command parameters for , congratulations , It's really used Corssgen2 Tools . But optimization ？ It just optimizes the portal assembly

Really want to have a larger optimization , It is necessary to pass other assemblies except the entry assembly Crossgen2 Tool execution ReadyToRun Only in this way can there be greater improvement . For example, one of my large applications , During the startup process WPF About one tenth of the modules in the framework have been touched once , Use JitInfo.GetCompiledMethodCount come to know , In the first window Show Before coming out 5 Ten thousand method calls . The percentage of portal assemblies in this application is too small , If the official method is used , Only the entry assembly ReadyToRun So the performance is really .NET Framework Complete abuse

In order to make dotnet 6 The startup performance of the application is comparable to .NET Framework Application startup performance , May adopt ReadyToRun For standard .NET Framework Of NGen technology . The following will show you how to use Crossgen2 Tool pair DLL Conduct ReadyToRun Improve startup performance

default Crossgen2 Tools are used NuGet Distributed DotnetPlatform Type of NuGet package , It contains the independently released Crossgen2 Tools . let me put it another way , Can be in  %localappdata%\..\..\.nuget\packages\microsoft.netcore.app.crossgen2.win-x64  Find this tool . If not , Try a sentence  dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true  Order to let dotnet In order to build ReadyToRun And help you Crossgen2 download

The above Crossgen2 Put the tools on  microsoft.netcore.app.crossgen2.win-x64  In the folder , there  win-x64  It doesn't mean Crossgen2 Ability of tools , Not that the tools in this folder can only build win-x64 Of . But the tool itself is win-x64 Of . This tool can build other platforms AOT Of . In other words, in Windows Of 32 In the bit system , The tool that will pull is  microsoft.netcore.app.crossgen2.win-x86  My bag

Enter the version number folder , Enter again Tools You can find it in the folder  Crossgen2.exe  Executable file , This is the tool article . For example, the tool path on my device is

C:\Users\lindexi\.nuget\packages\microsoft.netcore.app.crossgen2.win-x64\6.0.5\tools\Crossgen2.exe

Next, I will tell you how to use this tool

The use of this tool requires the input parameters. The recommendation is rsp file , The approximate command line calls are as follows

C:\Users\lindexi\.nuget\packages\microsoft.netcore.app.crossgen2.win-x64\6.0.5\tools\Crossgen2.exe "@C:\lindexi\Fxx\F1.rsp"

The specific parameters are placed in rsp In the document , The general content is as follows

--targetos:windows--targetarch:x86--pdb-O-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-console-l1-1-0.dll"-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-console-l1-2-0.dll"-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-datetime-l1-1-0.dll"-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-debug-l1-1-0.dll"-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-errorhandling-l1-1-0.dll"-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-fibers-l1-1-0.dll"-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-file-l1-1-0.dll"-r:"C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App\6.0.5\api-ms-win-core-file-l1-2-0.dll"--out:"C:\Users\linde\AppData\Local\Temp\Crossgen2\Crossgen2\KokicakawheeyeeWhemhedawfelawnemhel.dll"C:\lindexi\Code\empty\KokicakawheeyeeWhemhedawfelawnemhel\KokicakawheeyeeWhemhedawfelawnemhel\bin\release\net6.0-windows\win-x86\publish\KokicakawheeyeeWhemhedawfelawnemhel.dll

It consists of the following parts . Each line is an independent parameter , The contents are as follows

• --targetos:windows: System platform ready for execution . Conduct ReadyToRun Will generate AOT Code , This is strongly platform related , The platform must be specified

• --targetarch:x86： Prepare the generated corresponding platform , yes x86 still x64 etc.

• --pdb: This is optional , To generate PDB Symbolic file . If this sentence is not added, it will not generate PDB file . Generated PDB File is  ni.pdb  file , Cooperate with the original DLL Of PDB File can be used for debugging

• -O: This is optional , Indicates that optimization is required . amount to Release edition . It is recommended to add... By default , Otherwise, there will be little optimization effect , Or only reverse optimization effect

• -r:"xxx.dll": Many lines will be repeated here , The local path to the assembly file, one line at a time . Let the tool know which references can be found . The tool is preparing AOT The process , Need to find the referenced assembly . These parameters tell the tool where to put the corresponding assembly . You can add many more assemblies , Because it's just a reference to the tool , Tools will be based on their own needs , To find the corresponding assembly file . If the tool finds that the incoming data is redundant , That will automatically ignore the extra . It is recommended that the whole dotnet runtime All in , However, it should be noted that the added version must be consistent with the released version , Otherwise, if the startup process explodes , Then cool . If the application is published independently , Then list all in the application independent release folder DLL file , There is no need to add additional runtime folders

• --out:"xx.dll": Output file path after processing

• xxxxx.dll  Enter the path to the assembly

build rsp file , As a parameter , call Crossgen2 Tools , To complete the assembly ReadyToRun The process . Repeat the above process for multiple assemblies

What must be highlighted is , call Crossgen2 Tool execution ReadyToRun It may not improve the startup performance , This is a process that needs to be measured . Every DLL It is called. Crossgen2 Tool execution ReadyToRun It will change the file volume , The entire change will also affect startup performance . It is recommended to optimize application startup performance , Make adequate measurements , The method is as follows

Use Crossgen2 Tools for each DLL One time , Including the frame layer DLL Come again . And then one by one DLL Replace , Measure application startup performance . If you find something DLL the ReadyToRun Instead, it reduces startup performance , Or some DLL The increased file size is not cost-effective compared with the optimization of startup performance , That's not right DLL To optimize

Here are the test pairs dotnet runtime Bottom and WPF Framework of the DLL Conduct ReadyToRun After the optimization , Yes walterlv The impact of the startup performance of an application of the boss , It is worth mentioning that for different applications , The test data will be very different , The core reason is that different application startup processes will access different modules

This data is of little reference value , Because for different applications , The above results will change . If you want to use ReadyToRun Technology improves application startup performance , Please also measure each DLL after ReadyToRun Impact on startup performance . If you have enough time , It can also be measured on multiple DLL Effect of optimized combination on startup performance

A large application of my team , After a ReadyToRun Technology optimization , The startup performance is improved by 30%

But it must also be noted that , Not all applications use ReadyToRun Can optimize the startup performance , For example, one of my small applications , As long as you use ReadyToRun technology , The startup performance is basically reduced . in general , use ReadyToRun Technology requires performance measurement

Reference documents

WPF dotnet Using native images native Optimize dotnet framework Binary

WPF adopt ReadyToRun Lifting performance

Conversation about crossgen2 - .NET Blog

runtime/crossgen2-compilation-structure-enhancements.md at main · dotnet/runtime

runtime/Program.cs at main · dotnet/runtime

Compile configuration settings - .NET Microsoft Docs

ReadyToRun deployment overview - .NET Microsoft Docs

utilize PGO promote .NET Program performance - hez2010 - Blog Garden

JitInfo.GetCompiledMethodCount(Boolean) Method (System.Runtime) Microsoft Docs