CLR 2.0 vs 4.0 performance?

Question

Will a .NET program compiled for CLR 2.0 run faster if running unden CLR 4.0?

app.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0.30319" sku=".NETFramework,Version=v4.0,Profile=Client" />
    <supportedRuntime version="v2.0.50727"/>
  </startup>
</configuration>

Answer 1

Typically, no - it will be identical.

By default, the CLR 4 runtime will load the CLR 2 runtime to execute your CLR 2 code base. Forcing execution under CLR 4 requires setting useLegacyV2RuntimeActivationPolicy in your app.Config.

If you add that flag, then it will run in v4 of the CLR. In general, the performance is likely to be very similar, but it may differ slightly with the new runtime, due to changes in the JIT and core runtime. There is no guarantee that CLR 4 will be faster - it may be slower at times, though in general, I would expect the performance to be very close under both runtimes.

If you're having performance issues, profile your application. Changing the runtime will not fix a performance issue. Profiling your application while running under both will be the only way to know if it makes a difference for you, however.

Answer 2

Usually: No .

There are a couple of corner cases were performance improved, ie if the application floods the ThreadPool with small pieces of work then the work-stealing ThreadPool optimizations will be a big win. This could also significantly change the order the work is performed, so some apps that accidentally rely on ordering could crash.

There are similar kinds of corner cases in the background GC (med-large object compacting) and Interop (object locking changes).

Summary

If the performance of a .NET 3.5 (CLR 2.x) app is worse than expected then try the app on .NET 4.5 (CLR 4.x).

Answer 3

Generally speaking, not noticeably. The runtimes are all backwards-compatible, and AFAIK libraries found in older versions were only modified if the language spec changed (for instance adding covariance/contravariance support) or it was identified as a real memory/CPU hog.