What's Coming in .NET Runtime Performance in Version V3.5 SP1
What's Coming in .NET Runtime Performance in Version V3.5 SP1
It certainly has been a while since I last blogged. Most of this is laziness on my part, but I can truthfully say that it is partly because I have been busy trying to get the next servicing release of the .NET framework (called Version 3.5 Service Pack 1) out the door. Part of the framework (runtime + libraries) servicing is an updated version of the runtime DLL (which we call the CLR).
How do you know if you have an updated CLR? If the file
- c:\windows\microsoft.net\Framework\V2.0.50727\mscorwks.dll
has a version number greater than 50727.3000 then you have the changes I will be talking about. Because this is just a servicing of the runtime, we had to confine ourselves to changes that we felt had a very low chance of breaking existing applications. Nevertheless we were able to add substantial performance value. There are two changes I would like to talk about in particular.
- Improved Cold Startup performance
Cold startup time is the time it takes an application to start when all the data needed to run has to be fetched from disk (rather than from the operating system disk cache). The second time an application starts (Warm startup) is substantially faster because very few (slow) disk reads are needed to get the application running. It is not unusual for the warm startup time to be good (< 1 sec), but for the cold startup time to be quite bad (5-10 sec). In the new runtime we go to a lot of effort to pack all the code and runtime structures (for now only in DLLS associated with the framework itself), to reduce the amount of Disk I/O needed. While the improvements benefit all code that uses the framework, it helps the most on code that has been precompiled using NGEN.exe and the effect is more pronounced on larger applications.
- Inlining of value types (C# structs). (X86)
C# structs are what the .NET runtime calls value types. They are called this because when you have fields or arrays of such data structures, the value is embedded directly in the field (not referenced through a pointer). All the primitive types (int, char, bool) are value types, as well as a few types defined in the base class library like DateTime, Decimal, Point and Rectangle. The previous version of the code generator (for X86) did almost no optimization on value types. This was unfortunate, because although value types are not common (most types are classes, not structs), when they are used, they can be used heavily, and so optimization is important. In fact the biggest single piece of feedback we got on our feedback site related to performance was concerning more agressive inlining of value type methods. The runtime’s 64 bit code generators could already optimize value types, but the code generator for X86 could not. Since X86 is still the dominate platform there was an unmet need. In this servicing we included the work we did to enable this for X86. Your own code often may not benefit from this improvement (because it does not use value classes much), but if you do use them, you tend to use them heavily, and the value could be substantial.
64 Bit machines: X64
Much of the cold startup work was rearranging the data in precompiled framework executables to pack heavily used items together, and as such is applies equally well for 64 bit platforms like X64. However there are places where 64 bit machines are quite different (how exceptions are delivered by the operating system) and we did not invest heavily in tuning (packing) these places. The result is that cold startup wins will not be as dramatic on 64 bit machines. There were improvements to the 64 bit code generator, but since this code generator could already inline value types, we did not need to do work in that specific area.
64 Bit machines: Intel Itanium
Most users of the .NET runtime run it on the X86 processor, however beginning with Version 2.0 of the runtime also supports the Intel Itanium architecture. In fact, internally the Itanium version of the runtime came on line well before the X64 version did. The Itanium processor tends to be used in high end server applications, where scalability is a great concern. In the next major release of the Framework, we are continuing to investigate and improve our performance on the Itanium architecture. Microsoft is a charter member of the Itanium Solutions Alliance (ISA) and we are excited to work with the other members of ISA to further enhance the performance of the .NET Framework on Intel Itanium Architecture. Check out the CLR Performance Team’s blog on investigating Itanium perf for more on this work.
Comments
Anonymous
May 13, 2008
You've been kicked (a good thing) - Trackback from DotNetKicks.comAnonymous
May 14, 2008
Great news for everyone who cares about perfomance and read your blog, Vance! What about implementing IEquatable<T> by RuntimeTypeHandle? And will RuntimeTypeHandle.Equals be inlined to one intsruction as result of changes? And last question about Type.GetTypeHandle :) Is it still a call?Anonymous
May 14, 2008
There are various enhancements and even changes in SP1 . Perhaps one of the most interesting is the changeAnonymous
May 16, 2008
My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. Microsoft Downloads: Visual Studio Team System 2008 Capabilities White Papers . Symbols Package for Windows XP Service Pack 3 . ViaAnonymous
May 19, 2008
P&P/Design Patterns I have been in a customer situation where I have been using a combination ofAnonymous
August 19, 2008
In a previous posting , I mentioned that .NET V3.5 Service Pack 1 had significant improvements in the