在 VB6 COM Interop 下运行的 UI 性能问题
我们有一个 VB6 应用程序，它通过 COM 注册的 .NET tlb 启动我们的 .NET 代码。
任何在 VB6 进程下运行时启动的 .NET UI（我们有 WinForms 和 WPF）第一次都会显得非常缓慢。当从我们的 .NET 测试客户端（只是一个简单的 WPF 应用程序）运行时，任何新窗口都会立即显示。
这里没有发生数据访问。新窗口/窗体出现所需的时间似乎与其上的控件数量有关。例如，一个空白窗口/窗体会立即显示，但其中包含 5 个或 10 个控件的窗口/窗体可能需要长达 5 秒的时间。我们的一些.NET表单/窗口在VB6进程下运行时需要长达10秒的时间才能首次显示，这是不可接受的。
这似乎不是“整体应用程序预热”问题，因为每个不同的表单/窗口都会单独出现延迟。换句话说，如果我在.NET 中有 Form1 和 Form2，则第一次显示 Form1 需要 10 秒。然后第一次显示 Form2 也需要 10 秒。然而，在 VB6 进程的生命周期内随后启动相同的窗体/窗口总是瞬时的。此外，热启动与冷启动似乎确实有所不同......但同样，它是基于每个表单/窗口的。因此，如果我不预热 Form1，显示 Form2（在同一个 .NET dll 中）的性能仍然很差。
我已将 VS .NET 调试器附加到 VB6 进程，发现几乎整个 10 秒都花在 ShowDialog 下的 .NET 内部（而不是在我的代码中）。
该问题似乎在 WPF 和 WinForms UI 中同样存在。
关于如何进一步解决这个问题有什么想法吗？
We have a VB6 application that launches our .NET code via a COM registered .NET tlb.
Any .NET UI (we have both WinForms and WPF) that launches when running under the VB6 process appears very slowly for the first time. When running from our .NET test client (just a simple WPF application), any new windows show up right away.
There's no data access happening here. The amount of time it takes for a new window/form to appear seems relative to the number of controls on it. For example, a blank window/form shows up instantaneously, but one with 5 or ten controls on it can take up to 5 seconds. Some of our .NET forms/windows take up to 10 seconds to show up for the first time when running under the VB6 process, which is unacceptable.
This doesn't appear to be an "overall application warmup" issue, since the delays present individually for each different form/window. In other words, if I have Form1 and Form2 in .NET, the first time Form1 is shown takes 10 seconds. And then the first time Form2 is shown it also takes 10 seconds. However, subsequent launches of the same forms/windows within the lifetime of the VB6 process are always instantaneous. Additionally, warm start vs cold start does seem to make a different...but again, it's on a per form/window basis. So if I don't warm up Form1, the performance of showing Form2 (in the same .NET dll) is still poor.
I've attached my VS .NET debugger to the VB6 process and found that almost the entire 10 seconds is spent inside the .NET internals under ShowDialog (not in my code).
The problem seems to present equally in both WPF and WinForms UI.
Any ideas on how to troubleshoot this further?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我怀疑几乎所有这些都是 CLR 启动延迟加上 JIT 编译延迟。这里的区别可能是您根据需要启动 JIT 编译器的实例，甚至可能启动额外的进程内 CLR 实例。
进程内并行
I'd suspect almost all of this is CLR startup delay plus JIT compile delays. A difference here is probably that you are starting instances of the JIT compiler on demand, and possibly even additional in-process CLR instances.
In-Process Side-by-Side
是否有可能隐含地发生其他活动？您提到这个应用程序是 WPF，它充满了自动数据绑定等等。我将采取以下步骤：
我真的不认为问题出在 Interop 上。
Is it possible that other activity is happening implicitly? You mentioned that this app is WPF which is rife with automatic data binding and all that. I'd take these steps:
I really do not think the problem is Interop.