5. August 2018
With all the interesting improvements that the team at Microsoft are undertaking relating to performance improvements, I would like to highlight a new preview release that they have provided for new performance enhancements.
Here is just a overview summary of what they have talked about, you can read more in their main article below.
Compilation with .Net Framework
- Historically compilation performed with tradeoffs, with combination of PreJitting to optimize code for steady state performance, but is slow and will affect initial start time.
- Alternative method like an econoJit approach that will start fast but code quality will suffer.
- .Net provides a combination in order to take a balanced approach that will provide a reasonable job for both start up and steady state peformance.
Tiered performance allows .Net to have multiple compilations so that they can be hot swapped, so we can pick best technique for startup and best for steady state performance.
the benefits of this are:-
- Faster application startup time
- Tiered compilation ask JIT to compile quickly and optimise if needed.
- Faster steady state performance
- Tiered compilation ask JIT to create optimised code in background thread that will replace the pre compiled version.
To try this:-
- If you build the application yourself using .NET 2.1 SDK – Add the MSBuild property <TieredCompilation>true</TieredCompilation>to the default property group in your project file. For example:
- If you run an application that has already been built, edit runtimeconfig.json to add System.Runtime.TieredCompilation=true to the configProperties. For example:
- If you run an application and don’t want to modify any files, set the environment variable
There has been much confusion about .Net Core and .Net Standard and why they have come about, I have added a good article by Microsoft about how to demystify the difference between them.
.Net Core 1 was release first and was the first iteration in the .Net Core stack to offer a new approach to developing using the .Net technology. Recently however .Net Standard has been introduced in order to provide some cross compatibly between various mobile technologies and applications. When this was announced many of the early adopter of .Net Core questioned this and the amount of time and resources already invested in applications, they demanded that .Net Standard be integrated with .Net Core.
When would we use one over the other?
This decision hinges on the technology requirement of compatibility that .Net Standard provides over the vast number of APIs available to .Net Core.
.Net Core increases the Api access surface area available however its implementation allows only those that target .Net Core applications.
.Net Standard however can be used by any application that targets the specific .Net Standard version but has a decreased Api access surface area.
An example of this would be if the .Net Standard version 1.4 was being used in a specific application, then all those applications that also target that version are able to support the .Net Standard version. On the other hand they will not have access to some Api parts such as the microsoft.netcore.coreclr.
What are the differences in the Api surface area?
.Net Standard applications include the netstandard.library, whereas .Net Core includes microsoft.netcore.app which has around 20 additional libraries that’s available to it.
.Net standard can be added manually but some functionality will not be compatible such as Microsoft.NETCore.CoreCLR. However the trade-off is that .Net Standard increases portability and all the benefits it brings is this new age of mobile first development. It also provides a contract agreement between applications as to what versions they are targeting agree to. .Net Standard exists to run on multiple runtimes whereas .Net Core provides an increased surface area and have to specify the platform that the application is run against.
Read original article https://msdn.microsoft.com/en-us/magazine/mt842506