Are .NET 4.0 Runtime slower than .NET 2.0 Runtime?
.net, .net-4.0, benchmarking, performance, visual-studio-2010
Solution
I think I've got it.
If you're running on a 64 bit machine, make sure the build is set to "Any CPU" rather than "x86". Doing that fixed the issue on my machine.
The default for new projects changed in VS2010 from "Any CPU" to "x86" - I believe this was to make Edit and Continue work by default on 64 bit machines (as it only supports x86).
Running an x86 process on a 64 bit machine is obviously somewhat suboptimal.
EDIT: As per Dustin's comments, running x86 rather than x64 can have performance advantages in terms of more efficient use of memory (shorter references).
I also corresponded with Dustin about this by email, and he included these reasons:
FWIW, the default target platform wasn’t changed to support ENC. We had already shipped ENC broken on x64 for 2 releases. So by itself, ENC wasn’t really a compelling reason to switch. The primary reasons we switched (in no particular order) were:
IntelliTrace is not supported on x64. So, one of the coolest new features won’t work on x64 Windows for Any CPU projects.
x64 EXEs run slower on x64 Windows than x86 EXEs do. So, the idea of x86 debug, x64 release would mean that “optimized” builds in Release would actually perform worse.
Customer complaints when deploying an application and finding that it doesn’t work, even though it worked on their machine. These were often around P/Invoke, but there any many other assumptions that can be made in an application that can break when run with different bitness.
The above reasons coupled with the fact that an Any CPU brings no benefits (i.e. you can’t actually take advantage of the expanded address space because the EXE may still run on x86) was the reason that the default was switched.
Rick Byers has an excellent post on this topic here.
Problem
After I upgraded my projects to .NET 4.0 (With VS2010) I realized than they run slower than they were in .NET 2.0 (VS2008). So i decided to benchmark a simple console application in both VS2008 & VS2010 with various Target Frameworks: ``` using System; using System.Diagnostics; using System.Reflection; namespace RuntimePerfTest { class Program { static void Main(string[] args) { Console.WriteLine(Assembly.GetCallingAssembly().ImageRuntimeVersion); Stopwatch sw = new Stopwatch(); while (true) { sw.Reset(); sw.Start(); for (int i = 0; i < 1000000000; i++) { } TimeSpan elapsed = sw.Elapsed; Console.WriteLine(elapsed); } } } } ``` Here is the results: - VS2008 - Target Framework 2.0: ~0.25 seconds - Target Framework 3.0: ~0.25 seconds - Target Framework 3.5: ~0.25 seconds - VS2010 - Target Framework 2.0: ~3.8 seconds - Target Framework 3.0: ~3.8 seconds - Target Framework 3.5: ~1.51 seconds - Target Framework 3.5 Client Profile: ~3.8 seconds - Target Framework 4.0: ~1.01 seconds - Target Framework 4.0 Client Profile: ~1.01 seconds My initial conclusion is obviously that programs compiled with VS2008 working faster than programs compiled with VS2010. Can anyone explain those performance changes between VS2008 and VS2010? and between different Target Frameworks inside VS2010 itself?