在客户站点比较 .NET 性能与 VB 6 性能的最佳方法是什么？

Question

两个问题：

1. 谁能指出我将 .NET 性能与 VB 6 性能进行比较的无偏数据？我已经搜索过，但很难找到。
2. 当应用在客户站点上运行时，将 .NET 性能与 VB 6 性能进行比较的最佳方法是什么？

我们有一个 WindowsForms 客户端-服务器应用程序（为 2.0 编写，很快升级到 3.5 SP 1），与之前的 VB 6 版本相比，某些客户抱怨“性能缓慢”。我知道，“性能缓慢”是非常模糊和笼统的，但是假设 .NET 代码可能比 VB 6 代码慢，因为 .NET 在 VM 中运行，这是真的吗？我 100% 用 C# 编写代码，所以它不是由第三方或向导移植的。

并非所有客户都会提出此投诉，因此我们怀疑存在环境问题。我们是在客户现场衡量绩效的唯一选择吗？我们的一些客户在 Novell 网络上的 Windows Server 2003 上使用 SQL Server 2005。与 Windows 网络上的类似机器相比，他们是否会看到截然不同的数据访问性能？

Answer 1

首先我需要提到的是 .Net 代码从不在 VM 中运行。虽然 .Net 程序确实被编译为类似于 Java 的 ByteCode 的 IL，但重要的区别在于 IL 在应用程序启动之前又被编译为完全原生代码，而不是由 VM 解释。

继续进行 .Net/VB6 比较。我不能指出具体的数据，但从个人经验来看，这取决于你在做什么。

为了说明这一点，让我们考虑六个不同的基准测试应用程序，每个应用程序都有一个 vb6 和 .Net 版本。每个应用程序选择一个特定的操作，执行 100,000 次，然后记录所用的时间。请注意，这是一个思想实验：我实际上还没有看到真实应用程序的结果。但我觉得我对这两个平台的优缺点都有一定的了解。

• 应用程序 A 进行了一些严重的 CPU 密集型数字运算。在这种情况下，我不得不相信这里的结果几乎是相同的。 VB6 和 .Net 都编译为本机代码，因此 cpu mult 指令无论如何都是相同的。也就是说，如果您不使用Option Strict，您可能很快就会在任一平台上遇到麻烦。由于您使用的是 C#（本质上始终是 Option Strict），这可能会给您的 .Net 代码带来优势。

• 应用程序 B 退出并从数据库中检索值。同样，结果可能非常接近，尽管出于两个原因我不得不给 .Net 一个非常小的优势：它使用本机 sql 客户端，据说速度更快，并且它执行自动连接池之类的操作并使其更容易分解出诸如连接一次并重新使用该连接而不是重复连接之类的事情。但如果就代码而言，如果您将苹果与苹果进行比较，两者可能会非常接近。

• 应用程序 C 反复显示和隐藏表单。在这里，我不得不给 vb6 点头。它基于较旧的、不那么炫目的小部件集，坦率地说，渲染成本更低。此外，WinForms 组件并不以速度如此之快而著称。但是，差异可能并不像您想象的那么大，而且您也可能不会经常完全重绘表格。这可能是您的用户抱怨的缓慢。

• 应用程序 D 是基于字符串操作的，在这里我不得不向 .Net 致敬。 VB6 和 .Net 都以慢速字符串操作而闻名。但是，.Net 提供了许多在 vb6 中根本不可用的工具来帮助开发人员克服缓慢的问题。也就是说，如果您不了解这些工具，那么糟糕的字符串操作选择很容易让您的应用程序陷入无用的工作。这也可能导致用户投诉。

• 应用程序 E 将重复地将 Xml 文档加载到内存中。同样，我不得不认为 .Net 会有优势。首先，vb 可用的所有 xml 工具充其量只是原始的。我发现它们不太可能没有得到显着改善。此外，.Net 的垃圾收集器非常聪明，可以在加载期间为其分配和释放内存。不过，我认为这里最重要的是磁盘速度，这意味着差异不会那么大。

• 应用程序 F 将重复启动 .Net 或 vb6 程序，等待它准备好（对于“准备好”的某些定义），然后关闭它。这里 vb6 可能具有优势，原因有两个。首先，.Net 必须在第一次运行时将 IL 编译为字节码。谢天谢地，这只是第一次运行。其次，.Net 应用程序还必须加载任何引用的程序集。相比之下，VB6 运行时要小得多。但是，这通常仅在您在特定机器上启动应用程序时第一次 是正确的，并且有一些方法可以预编译 .Net 代码。这也可能导致感知缓慢。

重要的一点是，对于所有这些应用程序，.Net 应用程序可能会有更多更大的内存占用。由于某些原因，开发人员倾向于认为这是一个糟糕的性能特征，而实际上恰恰相反。如果您的应用程序使用更多内存，则它可能花费更少的时间进入磁盘，并且磁盘速度较慢。它可能还缓存更多，从而节省了 cpu 时间。特别是对于 .Net，它会在更重要或电脑空闲时节省分配/解除分配操作。

我没有时间，但看到有人使用 today's Coding Horror 中提到的 StopWatch 实现（至少对于 .Net 方面）来获得每个指标的真正基准是很有趣的。

Answer 2

性能几乎总是取决于你在做什么。

如果可能，请到现场观察客户使用该应用的情况。找出减速发生的地方，然后对其进行分析 - 理想情况下使用类似数量的数据等。

检查客户站点的客户端和服务器的性能 - 找出真正导致问题的原因。检查网络配置和运行状况 - 愚蠢的设置有时可以让事情正常运行，但速度非常慢。

Answer 3

1. 我从未寻找过此类数据。您可能会查看经常用于基准测试的规范“宠物店”应用程序。它可能适用于两种开发平台。我怀疑＃2虽然要回答更重要。谁在乎宠物店是否跑得快。重要的是您客户的应用程序。

2. 大多数性能问题与数据库和/或网络有关。如果您在版本之间进行了重大的数据库更改，我将首先使用 SQL 跟踪/分析工具对那些进行分析，或者只是在关键的 procs/sql 上运行一些简单的测试，以支持您所谓的“低性能”表单。

如果我理解正确的话，它似乎在某些客户端上很好，但在其他客户端上却没有，有人在抨击你，因为它是 .NET 和 VB6 就很好，非常感谢。客户端之间的网络差异绝对是一个关键的差异。服务器操作系统、交换机的速度和网络基础设施等 - 有很多变量需要探索。但我敢打赌，这与 .NET 与 VB6 无关。

Answer 4

我知道我冒着听起来像是一个质疑问题而不是回答问题的人的风险，但请理解我提供这个完全是为了提供帮助。

在您更关心的情况下，即客户抱怨 .net 应用程序比 VB6 慢，如果您发现 VB6 确实更快，您是否认真考虑下转换？如果没有，为什么要浪费时间进行测试？

即使您可以最终证明您的客户是错误的，并且 .net 速度更快，您也不会通过驳回客户投诉来真正赢得任何东西。花时间解决问题而不是争论原因，最终每个人都会更快乐。

最后，我要指出的是，切换平台以获得更好的性能通常不是一项富有成效的努力，而且通常是让平台战争战胜常识的程序员的最后努力。我的建议是忽略已构建项目的 .NET/VB6 性能比较，只需花时间找出应用程序关注的特定领域并尽可能优化。

Answer 5

哦，很容易看到。在 WF 和 VB6 中复制并粘贴一个表单中的 50 个按钮，并并排比较它们的绘制速度。不是.NET慢，而是WF慢。我从来没有真正确定它，但促成因素：

• Button 类的绘制速度非常慢。它要求容器绘制背景以获得它没有的透明度。
• VB6 有几个无窗口控件，例如标签。在 WF 中，每个控件都是一个窗口。
• 视觉样式不是免费的。
• 他们非常努力地使 VB1 在 386SUX 上运行良好。

Answer 6

如果您实际上是在谈论用 VB 6.0 和 VB.NET 编写的相同客户端应用程序，那么 VB 6.0 应用程序很可能会更快地进入第一个屏幕（因为 .NET JIT 编译和程序集加载）。之后性能应该差不多。

问题是 - 在任何实际情况下 - 应用程序的架构都会不同，真正的性能比较没有意义，

Answer 7

.Net 粉丝有一千个借口。微软曾一度禁止比较，可能是有原因的。

.Net 速度慢的部分原因是运行时启动成本。其中一部分是 JIT 编译所需的时间。其中一部分是垃圾收集。部分原因是消耗了这么多内存的开销，这可能导致更多的交换。部分原因是在内联代码之外（即操作系统调用、许多标准库）涉及通过 COM 和/或 Win32 层来完成任务。

具有大量内存和多个快速 CPU 和硬盘驱动器速度的较新机器虽然掩盖了其中的一部分。屏蔽并不能减少浪费。

.Net 的目标与 Java 擅长的相同。快速编写的一次性代码和长时间保持加载和运行的服务器端内容。

Answer 8

与 VB6 应用程序相比的性能可能更多是由于应用程序设计而不是 c# 与 VB6。如果设计得当，我会猜测 C# 应用程序的 9.5/10 倍会更快。 .Net 不在虚拟机内部运行。 CLR JIT 将 .Net 应用程序编译为机器级代码，速度非常快。运行速度比非托管代码慢一点的原因是运行在沙箱下的 .Net 是托管的，这会产生一些开销。