CLR 2.0 与 4.0 性能比较？
如果在 CLR 4.0 下运行，为 CLR 2.0 编译的 .NET 程序运行速度会更快吗？
应用程序配置：
<?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>
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>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
通常情况下，不会 - 它会是相同的。
默认情况下，CLR 4 运行时将加载 CLR 2 运行时来执行 CLR 2 代码库。在 CLR 4 下强制执行需要设置
useLegacyV2RuntimeActivationPolicy在你的应用程序配置中。如果添加该标志，那么它将在 CLR v4 中运行。一般来说，性能可能非常相似，但由于 JIT 和核心运行时的变化，新运行时的性能可能会略有不同。不能保证 CLR 4 会更快 - 有时可能会更慢，但总的来说，我希望两个运行时下的性能非常接近。
如果您遇到性能问题，请分析您的应用程序。更改运行时不会解决性能问题。然而，在两者下运行时分析您的应用程序将是了解它是否对您产生影响的唯一方法。
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
useLegacyV2RuntimeActivationPolicyin 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.
一般来说，不明显。运行时都是向后兼容的，据我所知，旧版本中的库只有在语言规范发生变化（例如添加协变/逆变支持）或被识别为真正的内存/CPU 占用时才会被修改。
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.
通常：否。
有一些极端情况性能得到了改进，即，如果应用程序用小块工作淹没线程池，那么窃取工作线程池优化将是一个巨大的胜利。这也可能会显着改变工作执行的顺序，因此一些意外依赖顺序的应用程序可能会崩溃。
在后台GC（中大型对象压缩）和Interop（对象锁定更改）中也存在类似的极端情况。
摘要
如果 .NET 3.5 (CLR 2.x) 应用的性能比预期差，请尝试在 .NET 4.5 (CLR 4.x) 上运行该应用。
Usually: No.
There are a couple of corner cases were performance improved, i.e. 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).