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

我们已经用VB.NET 4.0/VS2010编写了.NET应用程序，编译时所有项目都设置为调试和发布配置的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位机器上的一切都比较慢，所以我不太确定能否将其分解为具体的语句

---

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

事实证明，当我们从任何CPU编译转换到专门的x86，即在x64位平台上也以x86运行时，我们又回到了“良好的速度”。我最近在应用程序中遇到了同样的性能问题。是的，把它编译成x86解决了这个问题；然后它在两个平台上快速运行。但启动响应时间缓慢的真正原因是32到64位的迁移问题。我认为，当应用程序启动并通过JIT过程将代码转换为IL时，编译器会确定代码中存在的问题（如非类型安全代码），必须先解决这些问题，然后才能在64位模式下运行。我浏览了这篇文章，现在正试图通过应用程序来确定是哪些部分导致了这些问题。请参阅本文：。

---

我可以不去管它，因为它可以工作，但理想情况下，如果问题得到解决，它在64位模式下会运行得更好。

也有同样的问题——是的，应该归咎于JIT。通过明智地使用msgbox，将它缩小到一个需要10秒才能启动的方法（在调用大方法之前调用MessageBox，然后作为大函数的第一行），是的，只有在编译为AnyCPU时才看到这一点，而不是在显式x86时；而不是在调试中运行时

在我的例子中，它是一个5000行的Windows窗体

InitializeComponent

要证明这一点，请运行（提升的）

c:\windows\\ngen.exe install

，它将编译本机映像。如果这解决了它，那么是的，JIT是罪魁祸首

长期修复，或者：

• 每次部署程序重建本机映像时使用ngen（或使用ngen更新重建，但显然只在安装一次后才起作用）；（缺点是管理ngen映像和ngen所需的时间。这是我采取的路线，因为大型应用程序的总体性能会得到提升。）

• 或者您可以将属性
  添加到方法中。（在方法上禁用JIT，因此执行速度较慢，但您不需要支付JIT的初始开销，这对我们来说是昂贵的部分）

---

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

如果您的开发环境是64位的，请尝试在Visual Studio中使用

性能向导运行
探查器，但是，看看这是否对你有帮助：我注意到了完全相同的事情，并在这里发布了一个问题：不要假设任何事情。RedGate和JetBrains提供了大量评测应用的试验。尝试和猜测某个随机应用程序在何处陷入困境是徒劳的。通过直接编译到32位（作为32位进程运行），您回到了快速运行状态，这很好，但您是否找到了为什么应用程序启动时间更长的答案？您的x64服务器有多少RAM？我想到的一件事是，我们大量使用NetAdvantages WinForms。我倾向于认为他们使用的代码在32位环境中执行得更快，但我还没有对此进行验证。在这方面有更多的经验是非常受欢迎的。还有RAM的问题：我们在所有机器上都有RAM的负载，同样的速度，在执行期间也有备用RAM的负载，所以它必须在其他地方。记住，
平台目标
不会更改编译的IL代码，它只是
JIT编译器
的一个限制。当使用本机api（为特定平台目标编译）时，该限制最有用！请发布更多，当你更深入地研究它。