In this post we are going to discuss the performance improvement in .net framework 4.5 in the area of Just In Time [JIT] compilation. As we know the .net applications are compiled into Intermediate Language [IL] code. This is irrespective of the programming language chosen to develop the application. Now when the application is run, the IL code is read by the CLR and JIT compiled into native code for the particular machine.
So the compilation from the IL Code to the native code happens when the application is actually running. So it shouldn't take a long time to understand that we can improve application performance if we could avoid this. One way to do this is to generate native code using Native Image Generator i.e. NGen.exe. In this case the assembly's native images is loaded from the Native Image Cache from GAC [Global Assembly Cache]. The other option is to still do it dynamically just in time but somehow improve the performance of this JIT compilation. This is exactly what is added to .net framework 4.5.
.net framework 4.5 supports this optimization using application profiles. Now we can enable the profile optimization for an application. Based on the historic profile, it keeps JIT compiling the methods in the background. So when the code is actually needed for execution, it is already in native format so the runtime doesn't have to wait for this.
Now let's see how we can enable an application for this optimization using profiles. In order to support this feature, a new type is added to System.Runtime namespace in mscorlib.dll assembly. As you could guess, this is named as ProfileOptimization class. In the following code, we are setting the directory where the profile would be stored. Next we are starting to profile the application.
The CLR creates the file for profile in the specified folder as follows:
Generally, while improving the performance of an application, we look forward to improve the different features provided by the application irrespective of the usage scenarios. Since this JIT compilation is based on past usage of the application, the application would be optimized differently based on these profile files. This is custom optimization of software based on temporal use of the feature. This is because if I have used a feature today, there is a high probability I would be using the application similarly as I am using it today. The runtime is just keeping the usage pattern in persistence and would use it for future use of the application. Since this is based on past profiles, there wouldn't be any advantage the first time the application is running.
It must be remembered that ProfileOptimization is just beneficial for applications running on multicore machines. It's usage is simply ignored if the application is running on a single core machine. There would be no profiling and hence no resulting optimization.
Please remember that Profile Optimization is different than Profile Guided Optimization, another features introduced in .net framework. Profile Guided optimization is about improving the layout of native libraries, not running on CLR, based on some test scenarios. Profile Optimization is about background [JIT]ing the application using mutlicore extra resources. On the other hand Profile Guided Optimization is a compiler optimization technique which improve the native image layout based on some test scenarios. It would definitely be better that compiler heuristic but it definitely wouldn't be based on the actual usage of the system which could be different than the selected test scenarios. Microsoft has included some extra tools in Visual Studio 2012 to make the guided optimization better including MPGO [Managed Profile Guided Optimization] tool.
[Note] This is enabled by default for ASP.net 4.5 and Silverlight 5 applications.