2
votes

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?

2
Message dispatching is slow for some reason. Use Spy++ to see how many messages are being processed by your VB6 windows while the .NET window is busy painting. - Hans Passant

2 Answers

0
votes

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

0
votes

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:

  1. Turn on the SQL Profiler and see if any calls are being made.
  2. I'd run it through the Ants profiler or the built-in one and see where the problem is.
  3. Fire up ProcMon and see what files are being accessed.
  4. See if you can ngen assemblies. Does the problem go away? If so, it could be the JIT compiler, though I doubt that is the case.

I really do not think the problem is Interop.