.NET Framework 4.5.1 Preview の記事の続きをもう少しだけ書いてみる

　あと少しだけ、昨日の記事 で書けなかったことを追加します。今日は、プールにいってほぼ一日炎天下にいたため、肩・背中がヒリヒリ痛いです。なので、手短に。

　LOHの扱いは、どの程度改善したんでしょうか？

On-demand large object heap compaction

Uservoice feature completed: LOH compaction (18 votes)

　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.

　.NET Framework 4.5 でリリースしたときのMulti-core JIT はどんな感じだったかな？

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.

　Visual Studio, .NET Framework は NuGet 推しなのですね。確かに、現状Visual Studio を使用している上で NuGet を使っていないと面倒なことが多いです。

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.

以上です。

※ああ、肩・背中、あと顔が痛い....