在客户站点比较 .NET 性能与 VB 6 性能的最佳方法是什么？
有两个问题：
- 有人能给我提供比较 .NET 性能与 VB 6 性能的无偏见数据吗？ 我已经搜索过了，但出乎意料的是很难找到。
- 当应用程序在客户站点上运行时，比较 .NET 性能与 VB 6 性能的最佳方法是什么？
我们有一个 WindowsForms 客户端-服务器应用程序（为 2.0 编写，很快升级到 3.5 SP 1），某些客户抱怨与以前的 VB 6 版本相比“性能缓慢”。 我知道，“性能低下”是非常模糊和笼统的，但是因为 .NET 在虚拟机中运行而假设 .NET 代码可能比 VB 6 代码慢，这是真的吗？ 我 100% 的代码都是用 C# 编写的，因此它不是由第三方或向导移植的。
并非所有客户都会提出这样的投诉，因此我们怀疑存在环境问题。 我们是衡量客户现场性能的唯一选择吗？ 我们的一些客户在 Novell 网络上的 Windows Server 2003 上使用 SQL Server 2005。 他们是否会看到与 Windows 网络上的类似机器截然不同的数据访问性能？
Two questions:
- Can someone point me to unbiased data that compares .NET performance to VB 6 performance? I have searched but it is surprisingly difficult to find.
- What is the best way to compare .NET performance to VB 6 performance as an app behaves at a customer's site?
We have a WindowsForms, client-server app (written for 2.0, upgrading to 3.5 SP 1 soon) about which certain customers complain of "slow performance" as compared to the previous VB 6 version. I know, "slow performance" is very vague and general, but is it true to assume .NET code might be slower than VB 6 code because .NET runs in a VM? I wrote 100% of the code in C#, so it was not ported by some third person or wizard.
Not all customers make this complaint, so we suspect something environmental. Is our only option to measure performance at a customer site? Some of our customers use SQL Server 2005 on Windows Server 2003 on a Novell network. Would they see dramatically different data access performance than a similar machine on a Windows network?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我需要提到的第一件事是 .Net 代码永远在虚拟机中运行。 虽然 .Net 程序确实被编译为 IL，这在某种程度上类似于 Java 的 ByteCode，但重要的区别在于 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，它可以在更重要的时间段或电脑处于空闲状态时节省分配/释放操作。
我没有时间，但是看到有人使用 今天的编码恐怖 以获得每个这些的真正基准。
The first thing I need to mention is that .Net code never runs in a VM. While it's true .Net programs are compiled to IL that is somewhat analogous to Java's ByteCode, the important difference is that the IL is also in turn compiled to fully native code before the app starts, rather than interpreted by a VM.
Moving on to the .Net/VB6 comparison. I can't point to specific data, but from personal experience it depends on what you're doing.
To illustrate this, let's think about six different benchmark applications, each with a vb6 and .Net version. Each application picks out a specific operation, performs it 100,000 times, and then records the amount of time taken. Note that this is a thought experiment: I haven't actually seen results from real apps. But I feel like I have a sense of the strengths and weaknesses of both platforms.
Application A does some serious cpu-heavy number crunching. In this case, I have to believe the results here would be almost identical. Both VB6 and .Net compile down to native code, and so a cpu
multinstruction is the same regardless. That said, if you're not usingOption Strictyou could quickly get yourself in trouble on either platform. Since you used C# (which essentially is alwaysOption Strict), that could give your .Net code an advantage.Application B goes out and retrieves a value from a database. Again, results are probably very close, though I'd have to give .Net a very slight edge for two reasons: it uses a native sql client, which is supposedly a little faster, and it does things like automatic connection pooling and makes it easier to factor out things like connecting once and re-using that connection rather than connecting repeatedly. But if you compare apples to apples as far as code goes, the two will likely be very close.
Application C shows and hides a form repeatedly. Here I would have to give vb6 the nod. It's based on an older, less glitzy widget set which will frankly be cheaper to render. Also, the WinForms components aren't known for being all that speedy. However, the difference probably isn't as large as you might think, and you're probably not completely redrawing forms that often, either. This is likely the slowness that your users complain about.
Application D is based on string operations, and here I have to give the nod to .Net. Both VB6 and .Net are known for slow string operations. However, .Net provides a number of tools that are simply not available in vb6 to help developers overcome the slowness. That said, if you're not aware of those tools, poor string operation choices could easily bog down your app doing useless work. This is also likely contributing to user complaints.
Application E is going to repeatedly load an Xml document into memory. Again, I have to think that .Net would have an advantage. First of all the xml tools available to vb were primitive at best. I find it unlikely they haven't been improved significantly. Additionally, .Net's garbage collector is pretty smart, giving it an advantage or allocated and freeing memory during the loads. However, I think the biggest thing here is going to be disk speed, which means the difference wouldn't be that large.
Application F will repeatedly start a .Net or vb6 program, wait for it to become ready (for some definition of "ready"), and then close it. Here vb6 likely has the advantage, for two reasons. Firstly, the .Net has to compile the IL to bytecode on the first run. Thankfully, that's only the first run. Seconly, the .Net app also has to load any referenced assemblies. By comparison, the VB6 runtime is much smaller. However, this is normally only true the first time you start the app on a particular machine, and there are ways to pre-compile the .Net code. This may also contribute to perceived slowness.
One important point is that for all of these applications, the .Net app is likely going to have a much larger memory footprint. For some reasons developers tend to think about this as a bad performance characteristic when in fact the opposite is true. If your app is using more memory, it's probably spending less time going to disk, and the disk is slower by far. It's probably also caching more, which saves cpu time. And for .Net specifically, it's saving up allocation/deallocation operations for periods when it's more important or when the pc is otherwise idle.
I don't have time, but it's be interesting to see someone use the StopWatch implementation (at least for the .Net side) mentioned in today's Coding Horror to get real benchmarks for each of these.
性能几乎总是取决于您正在做什么。
如果可能，请前往现场观察客户使用该应用程序。 找出速度下降的地方，然后对其进行分析 - 最好使用类似数量的数据等。
检查客户站点的客户端和服务器的性能 - 找出实际上导致问题的原因。 检查网络配置和运行状况 - 愚蠢的设置有时可以让一切正常运行，但速度却非常慢。
Performance pretty much always depends on what you're doing.
If possible, go on-site and watch the customer using the app. Find out where the slowdown is happening, then profile that - ideally with a similar amount of data etc.
Check the performance of both the client and the server at the customer site - find out which is actually causing the problem. Check the network configuration and health - silly settings can sometimes keep things working but painfully slow.
我从来没有寻找过这种数据。 您可以查看通常用于基准测试目的的规范“Pet Shop”应用程序。 它可能在两种类型的开发平台中都可用。 我怀疑#2 的回答更为重要。 谁在乎宠物店跑得快不快。 重要的是您客户的应用程序。
大多数性能问题都与数据库和/或网络相关。 如果您在版本之间进行了重大的数据库更改，我会首先使用 SQL 跟踪/分析工具来分析这些更改，或者只是对关键 procs/sql 运行一些简单的测试，以支持您所谓的“性能低下”表单。
如果我理解正确的话，似乎对某些客户来说没问题，但对另一些客户则不然，并且有人在打击你，因为它是 .NET 而 VB6 就很好，非常感谢。 客户端之间的网络差异绝对是一个关键的差异。 服务器操作系统、交换机速度和网络基础设施等——有很多变量需要探索。 但我愿意打赌这与 .NET 与 VB6 无关。
I haven't ever looked for this kind of data. You might look at the canonical "Pet Shop" app that is often used for benchmarking purposes. It's probably available in both flavors of dev platform. I suspect #2 is far more important to answer though. Who cares if Pet Shop runs quickly. It's your customer's app that matters.
Most performance issues are database and/or network related. If you made significant database changes between versions, I'd profile those first using the SQL tracing/profiling tools or just running some simple tests on key procs/sql that execute to support your so called "slow performance" forms.
If I understand you correctly, it seems to be fine at some clients but not at others, and somebody is hammering you on the fact that it is .NET and VB6 was just fine, thank you very much. Network differences between clients is definitely a critical difference. Server OS, speed of switches and network infrastructure, etc. - so many variables to explore. But I'd be willing to bet it has nothing to do with .NET vs. VB6.
我知道我冒着听起来像一个提出问题而不是回答问题的人的风险，但请理解我完全本着试图提供帮助的精神提供此信息。
在您更关心的情况下，即客户抱怨 .net 应用程序比 VB6 慢，如果您发现 VB6 确实更快，您是否会认真考虑下转换？ 如果没有，为什么要浪费时间进行测试呢？
即使您能够最终证明您的客户是错误的并且 .net 更快，但您并不能通过驳回客户投诉来真正赢得任何东西。 花时间解决问题而不是争论原因，最终每个人都会更快乐。
最后，我要指出的是，切换平台以获得更好的性能通常不是一种富有成效的努力，而且通常是让平台之战战胜常识的程序员的最后一搏。 我的建议是忽略已构建项目的 .NET/VB6 性能比较，而只花时间找出应用程序关注的特定领域并尽可能进行优化。
I know I am running the risk of sounding like the guy who questions the question instead of answering it, but understand that I am offering this completely in the spirit of trying to be helpful.
In the context of your bigger concern, that is customers are complaining the .net app is slower than VB6, are you seriously considering downconverting if you find out that VB6 is indeed quicker? If not, why waste the time with testing?
Even if you can conclusively prove your customers wrong and .net is faster, you don't really win anything by dismissing customer complaints. Spend the time solving the problem rather than debating the causes, in the end everyone will be happier.
Finally, I will note that switching out platforms to get better performance is generally not a productive endeavor and is usually a last ditch effort by programmers who let platform wars win out over common sense. My suggestion is ignore the .NET/VB6 performance comparison for a project that is already built and just spend the time finding out the specific areas of concern for the application and optimize as best you can.
哦，很容易看出。 在 WF 和 VB6 中复制并粘贴表单中的 50 个按钮，并并排比较它们的绘制速度。 不是 .NET 慢，而是 WF 慢。 我从来没有真正确定过它，但影响因素是：
Oh, it's easy to see. Copy and paste 50 buttons in a form both in WF and in VB6 and compare their paint speed side by side. It is not .NET being slow, it is WF being slow. I never really nailed it down but contributing factors:
如果您实际上讨论的是用 VB 6.0 和 VB.NET 编写的相同客户端应用程序，那么 VB 6.0 应用程序很可能会更快地到达第一个屏幕（因为 .NET JIT 编译和程序集加载）。 之后，性能应该大致相同。
问题是 - 在任何实际情况下 - 应用程序的架构都会有所不同，并且真正的性能比较没有意义，
If you're talking about effectively the same client application written in VB 6.0 and VB.NET then the VB 6.0 app will most likely get to the first screen more quickly (because of .NET JIT compliation and asssembly loading). After that the performance should be about the same.
The problem is - in any real situation - the applications would be architeched differently and a true performance comparison would not be meaningful,
.Net 粉丝有一千个借口。 微软曾一度禁止比较，这可能是有道理的。
.Net 缓慢的部分原因是运行时启动成本。 其中一部分是 JIT 编译所需的时间。 其中一部分是垃圾收集。 部分原因是消耗大量内存的开销，这可能导致更多的交换。 部分原因是内联代码（即操作系统调用、许多标准库）之外涉及通过 COM 和/或 Win32 层进行重击以完成任务。
不过，具有大量内存和多个快速 CPU 和硬盘驱动器速度的新型机器掩盖了其中的一些问题。 掩盖并不能减少浪费。
.Net 的目标与 Java 所擅长的相同。 快速编写的一次性代码和服务器端内容可以长时间保持加载和运行。
The .Net fans have a thousand excuses. At one point Microsoft was prohibiting comparisons, probably with reason.
Part of the reason .Net is slow is the runtime startup cost. Part of it is time required to JIT compile. Part of it is garbage collection. Part of it is the overhead of having so much memory consumed, which can lead to more swapping. Part of it is that outside of inline code (i.e. OS calls, many standard libraries) involves thunking through COM and or Win32 layers to get things done.
Newer machines with vast memory and multiple fast CPUS and hard drive speeds masks some of this though. Masking doesn't make it less wasteful.
.Net was targeted at the same things Java is decent at. Fast-written throwaway code and server-side stuff that stays loaded and running for long intervals.
与 VB6 应用程序相比的性能可能更多地归因于应用程序设计，而不是 C# 与 VB6 应用程序的性能。 我估计，如果设计得当，C# 应用程序的速度将是 C# 应用程序的 9.5/10 倍。 .Net 不在虚拟机内部运行。 CLR JIT 将 .Net 应用程序编译为机器级代码，使其速度非常快。 运行速度比非托管代码慢一点的原因是运行的沙箱 .Net 是托管的，并且有一些开销。
The performance versus the VB6 app is probably due more to application design than c# versus VB6. I would guestimate that 9.5/10 times the C# app would be faster if designed properly. .Net does not run inside of a VM. The CLR JIT compiles a .Net app to machine level code, making it pretty darn fast. The reason is runs a bit slower than unmanged code is that the sandbox .Net run under is managed, and that has some overhead.