.Net 4.0 应用在64位系统上比32位系统运行速度慢（性能分析和可能的解决方案）（应用程序使用NetAdvantage）

Question

我们有一个用VB .NET 4.0 / VS2010编写的.NET应用程序，将所有项目设置为Debug和Release配置下的AnyCPU模式进行编译。我们注意到，当在64位环境（在Windows Server 2003 R2和2008 R2上测试）下运行该应用程序时，启动时间至少是32位环境（Win XP和7）中的两倍以上（绝对时间约为25秒，而不是6-12秒）。我应该补充说明，64位系统是功能强大的服务器，肯定比其他测试的32位系统更强大。所有其他应用程序在64位上都更快，但我们可怜的应用程序不是；）（我们确实在不同时间、负载下测试了应用程序，结果总是差不多。）

如上所述，该应用程序使用AnyCPU构建，并且在64位操作系统下运行为64位程序集（通过TaskManager检查）。该应用程序本身是一个WinForms应用程序，利用NetAdvantage Forms v10.3，并且经常查询和写入MS SQL Server 2008。

不同的目标机器都在同一网络上，因此例如数据库（性能测试使用相同的数据库）的路径是相同的，我认为问题不在于数据库或网络本身。

我注意到的一件奇怪的事情是，在使用秒表在我们的MainForm启动期间构建不同的“分析步骤”时，InitializeComponent方法在64位上需要两倍的时间，约为4秒，而在32位上为1.5秒。

我们在两个系统上部署相同的应用程序，没有不同的配置。

因此，我有两个问题：

有什么想法是什么原因？

以及：确定“有问题”的代码片段的最佳方法是什么？目前我使用秒表并尝试缩小范围。但是就我们的应用程序而言，似乎64位机器上的所有内容都比较慢，所以我不太确定能否将其分解为特定语句。

感谢大家的帮助，非常感谢。。。

- ManOnAMission

---

如果您的开发环境是64位，请尝试在Visual Studio中使用“性能向导”运行“Profiler”。 - Moon

很抱歉我没有完全阅读问题，但请检查这是否对您有所帮助：https://dev59.com/o3A85IYBdhLWcg3wF_cO - Adi Lester

我注意到了完全相同的事情，并在这里发布了一个问题：https://dev59.com/V1rUa4cB1Zd3GeqPk4sv - Boris B.

@Moon。不，这是一个32位的开发环境。但我可能会获得64位的开发环境。感谢您的提示。编辑：哦，但我们只有VS专业版 - 这行吗？ - ManOnAMission

不要假设任何事情，要进行测量。 - Hans Passant

Red Gate和JetBrains提供了出色的性能分析应用程序试用版。试图猜测某个随机应用程序存在问题的位置是徒劳无功的游戏。 - roken

Answer 1

我遇到了相同的问题 - 是JIT的问题。通过谨慎使用msgbox，我将问题定位在一个需要10秒才能启动的方法上（通过在调用大方法之前调用消息框，然后作为大函数的第一行调用）。只有在编译为AnyCPU时才发现这个问题，而在明确指定x86时以及在调试模式下运行时则没有出现。

在我的情况下，是一个5000行的Windows Forms InitializeComponent。

为了证明这一点，可以运行（提升权限）"

长期的解决方案有两种：

- 每次部署程序时都使用ngen重新构建本地映像（或者使用ngen update进行重建，但显然只需安装一次）；（缺点是管理ngen映像和ngen所需的时间。对于较大的应用程序，这是我选择的路线，因为整体性能会提高。） - 或者可以向该方法添加属性。 （禁用方法的JIT，使其执行速度较慢，但您不必支付JIT的初始开销，这是我们的昂贵部分）

（我怀疑两者都做是徒劳的，因为这意味着放弃大方法的本地映像而没有获得任何好处。）

- user2006616

Answer 2

事实证明，我们从编译AnyCPU切换到专门的x86（即在x64位平台上也以x86运行）后，我们又恢复了“良好的速度”。

- ManOnAMission

---

很好，你通过直接编译为32位并作为32位进程运行恢复了快速运行的速度，但是你是否找到了应用程序启动时间变长的原因？你的x64服务器有多少RAM？ - tap

我想到的一件事是，我们大量使用NetAdvantages WinForms。我倾向于认为它们使用的代码在32位环境下执行速度更快，但我还没有验证过。如果有更多相关经验，非常欢迎分享。关于RAM的问题：我们所有机器都有大量RAM，速度也相同，在执行期间还有大量的备用RAM，所以问题肯定出在其他地方。 - ManOnAMission

请记住，平台目标不会改变编译后的IL代码，它只是对JIT编译器的限制。这种限制在使用本地API（为特定平台目标编译）时非常有用。 - Jeroen van Langen

Answer 3

最近我遇到了一个应用程序的性能问题。是的，将其编译为x86解决了问题；它在任何平台上都运行得很快。但是慢启动响应时间的真正原因是由于32位到64位迁移问题。我认为当应用程序启动并经过JIT过程将代码转换为IL时，编译器确定代码中存在问题（如不安全的代码），必须在运行64位模式之前解决这些问题。我找到了这篇文章，现在正在尝试检查应用程序以确定哪些部分会导致问题。请参见此文章：http://msdn.microsoft.com/en-us/library/ms973190.aspx。 虽然它可以正常工作，但理想情况下，如果解决了这些问题，它将在64位模式下运行得更好。

- DavidC

---

有趣！请继续发布更多，当您进一步研究后。 - ManOnAMission