两个问题：
我们有一个 WindowsForms 客户端-服务器应用程序（为 2.0 编写，很快升级到 3.5 SP 1），与之前的 VB 6 版本相比，某些客户抱怨“性能缓慢”。我知道，“性能缓慢”是非常模糊和笼统的，但是假设 .NET 代码可能比 VB 6 代码慢，因为 .NET 在 VM 中运行，这是真的吗？我 100% 用 C# 编写代码，所以它没有被第三方或向导移植。
并非所有客户都提出此投诉，因此我们怀疑存在环境问题。我们是在客户现场衡量绩效的唯一选择吗？我们的一些客户在 Novell 网络上的 Windows Server 2003 上使用 SQL Server 2005。与 Windows 网络上的类似机器相比，他们会看到截然不同的数据访问性能吗？
性能几乎总是取决于你在做什么。
如果可能的话，去现场观察使用应用程序的客户。找出减速发生的地方，然后对其进行分析 - 理想情况下使用类似数量的数据等。
检查客户站点的客户端和服务器的性能 - 找出真正导致问题的原因。检查网络配置和运行状况 - 愚蠢的设置有时可以让事情正常运行，但速度非常慢。
我需要提到的第一件事是 .Net 代码永远不会在 VM 中运行。虽然 .Net 程序确实被编译为有点类似于 Java 的 ByteCode 的 IL，但重要的区别在于 IL 在应用程序启动之前又被编译为完全本机代码，而不是由 VM 解释。
继续进行 .Net/VB6 比较。我不能指出具体的数据，但从个人经验来看，这取决于你在做什么。
为了说明这一点，让我们考虑六个不同的基准测试应用程序，每个应用程序都有一个 vb6 和 .Net 版本。每个应用程序选择一个特定的操作，执行 100,000 次，然后记录所用的时间。请注意，这是一个思想实验：我实际上还没有看到真实应用程序的结果。但我觉得我对这两个平台的优势和劣势有所了解。
应用程序 A 进行了一些严重的 CPU 密集型运算。在这种情况下，我不得不相信这里的结果几乎是相同的。VB6 和 .Net 都编译为本机代码，因此mult无论如何 cpu 指令都是相同的。也就是说，如果您不使用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，它会在更重要或电脑空闲时节省分配/解除分配操作。
我没有时间，但是看到有人使用今天的 Coding Horror中提到的 StopWatch 实现（至少对于 .Net 方面）来获得每一个的真正基准是很有趣的。
我从来没有寻找过这种数据。您可能会查看经常用于基准测试的规范“宠物店”应用程序。它可能适用于两种开发平台。不过，我怀疑＃2 更重要的是要回答。谁在乎宠物店是否跑得快。重要的是您客户的应用程序。
大多数性能问题与数据库和/或网络相关。如果您在版本之间进行了重大的数据库更改，我将首先使用 SQL 跟踪/分析工具对那些进行分析，或者只是在关键 procs/sql 上运行一些简单的测试，以支持您所谓的“低性能”表单。
如果我对您的理解正确，那么在某些客户端上似乎很好，但在其他客户端上却不行，并且有人在锤击您，因为它是 .NET 并且 VB6 就很好，非常感谢。客户端之间的网络差异绝对是一个关键的差异。服务器操作系统、交换机的速度和网络基础设施等 - 有很多变量需要探索。但我愿意打赌它与 .NET 与 VB6 无关。
我知道我冒着听起来像一个质疑问题而不是回答问题的人的风险，但要明白，我提供这个完全是为了提供帮助。
在您更关心的情况下，即客户抱怨 .net 应用程序比 VB6 慢，如果您发现 VB6 确实更快，您是否认真考虑下转换？如果没有，为什么要浪费时间进行测试？
即使您可以最终证明您的客户是错误的并且 .net 更快，您也不会通过驳回客户投诉来真正赢得任何东西。花时间解决问题而不是争论原因，最终每个人都会更快乐。
最后，我要指出的是，切换平台以获得更好的性能通常不是一项富有成效的努力，而且通常是让平台战争战胜常识的程序员的最后努力。我的建议是忽略已经构建的项目的 .NET/VB6 性能比较，只需花时间找出应用程序关注的特定领域并尽可能优化。
哦，很容易看出来。在 WF 和 VB6 中复制并粘贴一个表单中的 50 个按钮，并并排比较它们的绘制速度。不是.NET慢，而是WF慢。我从来没有真正确定它，但促成因素：
如果您实际上是在谈论用 VB 6.0 和 VB.NET 编写的相同客户端应用程序，那么 VB 6.0 应用程序很可能会更快地进入第一个屏幕（因为 .NET JIT 编译和程序集加载）。之后的表现应该差不多。
问题是 - 在任何实际情况下 - 应用程序的架构都会不同，真正的性能比较没有意义，
.Net 粉丝有一千个借口。微软曾一度禁止比较，可能是有原因的。
.Net 速度慢的部分原因是运行时启动成本。其中一部分是 JIT 编译所需的时间。其中一部分是垃圾收集。部分原因是消耗了这么多内存的开销，这可能导致更多的交换。部分原因是在内联代码之外（即操作系统调用、许多标准库）涉及通过 COM 和/或 Win32 层来完成任务。
具有大量内存和多个快速 CPU 和硬盘驱动器速度的较新机器掩盖了其中的一些。掩蔽不会减少浪费。
.Net 的目标与 Java 擅长的相同。快速编写的一次性代码和长时间保持加载和运行的服务器端内容。
与 VB6 应用程序相比的性能可能更多是由于应用程序设计而不是 c# 与 VB6。如果设计得当，我会猜测 C# 应用程序的 9.5/10 倍会更快。.Net 不在虚拟机内部运行。CLR JIT 将 .Net 应用程序编译为机器级代码，速度非常快。原因是运行速度比非托管代码慢一点，因为运行在沙箱下的 .Net 是托管的，并且有一些开销。