On-demand large object heap compaction
NGEN ですか。.NET 3.5 のとき少しでも高速化するために。CORE系のアセンブリなども NGEN で プリコンパイルしていました。
Consistent performance before and after servicing the .NET Framework
One of the ways that we deliver great performance, on both Windows and Windows Server, is by pre-compiling the core .NET Framework assemblies into native images, via a tool called NGEN. We’ve been doing that for over a decade now. It makes sense to pre-compile these assemblies since they are loaded by all managed apps. Requiring every app to JIT-compile core .NET Framework code at every launch doesn’t make good performance sense. On mobile devices such as laptops and tablets, NGEN also helps with battery life. A CPU cycle saved by not JITing is also a battery unit saved.
Multi-core JIT improvements
You may recall that we shipped multi-core JIT in the .NET Framework 4.5. In this release, we expanded the feature significantly, to work better with ASP.NET. In The .NET Framework 4.5.1 Preview, multi-core JIT has been extended to support dynamically loaded assemblies, loaded with the Assembly.LoadFrom API and from an Appdomain.AssemblyResolve event handler. These APIs are not specific to ASP.NET, however, we found that they were used quite commonly in ASP.NET apps.
Last time, we demonstrated the use of multi-core JIT for client apps. This time, let's look at server apps. Here, you’ll see that we tested multi-core JIT with DotNetNuke. You can see that we saw an ~15% spedup.
以前(4.5の頃)は下記のような感じでした。MultiCore JIT を使うと使わないでは、50%くらい違ったのですね。それから、4.5.1では15%高速化したんですね。比較の仕方が同一ではないのでなんともいえませんが、期待はできます。
Real-world benefit of Multicore JIT
Let’s take a look at how this works in practice with a few real-world applications. Bing.com recently moved to Windows Server 2012 and the .NET Framework 4.5. Because of Multicore JIT, their ASP.NET based services now start up 50% faster, going from an average of around 155 seconds to just under 80 seconds. You can read more about the Bing.com results with Multicore JIT in their recent blog post.
We see NuGet as a great way to ship opt-in updates to those of you who want updates at a faster pace, without needing to make changes to the actual .NET Framework product. We see this approach as something of a sweet spot where we keep both the developers building software for the big boats and those building the next startup happy. The trick isn’t just releasing different software to different audiences. That’s easy. Instead, we plan to release updates on NuGet and to the .NET Framework itself that nicely compose and layer together, although they might be on significantly differently release cadences with different release process requirements. We are working with NuGet to make this experience even better moving forward.
We can now service NuGet packages published by the .NET Framework team on Windows Update. It isn’t that we expect a steady stream of these updates. In fact, we don’t at all. Going forward, if we find a (very) severe bug or issue in one of our NuGet packages, we’ll use Windows Update as one of our release vehicles for servicing. Obviously, we’ll continue to publish updates (serious or otherwise) to NuGet.org as our first course of action, and expect that app authors primarily adopt our updates that way.