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