Whidbey Beta 2 Coming Up
I came across a blog comment by a Microsoft employee, Hannes Preishuber, that the Whidbey beta 2 should be coming up in the next few days. This is a few weeks earlier than the the March 31 delivery date announced by Somasegar, corporate VP of Microsoft’s developer divisions, but still in line with statements made five weeks ago that the next Avalon and Indigo CTP, both dependent on Beta 2, will arrive in about “six weeks.” It’s about time.
There will be some changes from Beta 1.
- Beta 2 utilizes a “go live” license for both ASP.NET and WinForms. The beta runtime will be supported by Microsoft.
- The target size of the redistributable is rumored to be around 16 MB for Beta 2 versus 24 MB for Beta 1 and 23 MB for version 1.1.
- The .NET moniker is steadily going away. VB.NET and JScript.NET has already been changed to Visual Basic and JScript. Will we start hearing about WinFX, especially with Avalon and Indigo on the way?
- Editor & Continue is supported under C#. I was very impressed with quality of the implementation with my brief exposure to it.
- There are more modern icons included in the new builds.
- Many features have been dropped from the framework such as in areas of XML and WinForms printing supports.
- Several classes and interfaces have been renamed or changed. IEnumerable<T> now, for example, inherits from IEnumerable.
- Language completeness. C++/CLI should actually be implemented now. The nullable types syntax extension in C# should be fully baked in by now.
One thing that I plan on doing is some performance testing. Performance testing should be more meaningful with Beta 2, since it is a true beta—no new features, no interface changes, just a trial run for the actual release.
The Whidbey JIT compiler produces much more optimized code; applications under the first beta already perform faster than the current versions of .NET. (I think that the developers of NET 1.x were more concerned with correctness and shipping than with performance.)
Unfortunately, some of my prior .NET assumptions are going to break down, and much of knowledge of CLR internals, from Richter’s Applied Microsoft .NET Framework Programming and Don Box’s Essential .NET, Volume I: The Common Language Runtime, will probably be out of date. These are some of the areas that I plan on looking at:
- Reflection. According to Chris Brumme, Whidbey reflection was rewritten and optimized for performance. My examination of the Rotor source shows that Everett reflection wasn’t just unoptimized, but somewhat inefficient. Invoking a method through a MethodInfo object used to take about 400 times longer than a direct invocation—this is even after parsing the name and locating the method data. While developing in Beta 1, I did encounter an encouraging new internal method, InvokeMethodFast, in the callstack during a reflection call, so I am hopeful that we could actually see an order of magnitude performance improvement in this area.
- Exceptions. Exceptions are orders of magnitude slower than reflection; I recall doing some benchmark tests on exceptions and initially believing that the poor performance numbers were due to programming errors. I would love to see a major improvement in exception-handling performance, but I doubt we will see any gains here. The CLR guys are stubborn in their belief that exceptions are exceptional.
- Interface and Delegate Performance. Interfaces and delegates are reportedly faster in Whidbey. Delegate performance improvements are probably obtained by simply inlining the call—before, a delegate invocation used to require the overhead of two to three function calls. Some Microsoft bloggers indicated that the performance of the two are similar, which may be due to a common implementation.
- NGEN performance. NGEN applications use to perform more slowly than Jitted applications, because the JIT compiler had more information about the dynamic runtime environment and could optimize away indirections. For example, NGEN’ed assemblies would perform vtable indirections to call nonvirtual methods in other assemblies. Though NGEN has more time to statically compile applications, it didn’t actually offer richer optimizations beyond the JIT. The new Whidbey version of NGEN supports hardbinding of multiple assemblies within an application.
- Others. I think we will see much more aggressive inlining of methods and more extensive code optimizations. I am guessing that the JIT compiler will be smarter about inlining monomorphic and bimorphic virtual methods the way Java is now. I am also hopeful that the compiler now support the inlining of custom value types.
UPDATE: Apparently, a not quite "Beta 2" February CTP is making the rounds at the MSDN website, so we could still possibly see the beta at the end of the month.