Проблемы производительности пользовательского интерфейса, работающие под VB6 COM Interop - PullRequest
2 голосов
/ 21 февраля 2012

У нас есть приложение VB6, которое запускает наш .NET-код через зарегистрированный COM .NET tlb.

Любой пользовательский интерфейс .NET (у нас есть как WinForms, так и WPF), который запускается при запуске под процессом VB6, очень медленно отображается в первый раз. При запуске из нашего тестового клиента .NET (просто простое приложение WPF) сразу появляются все новые окна.

Здесь нет доступа к данным. Количество времени, которое требуется для появления нового окна / формы, кажется относительно количества элементов управления на нем. Например, пустое окно / форма появляется мгновенно, но одно с 5 или 10 элементами управления может занять до 5 секунд. Некоторые из наших форм / окон .NET при первом запуске в процессе VB6 могут отображаться до 10 секунд, что недопустимо.

Это не является проблемой "общего прогрева приложения", так как задержки присутствуют индивидуально для каждой отдельной формы / окна. Другими словами, если у меня есть Form1 и Form2 в .NET, первый раз, когда Form1 показывается, занимает 10 секунд. И тогда, когда показывается Form2 в первый раз, это также занимает 10 секунд. Однако последующие запуски тех же форм / окон в течение времени жизни процесса VB6 всегда происходят мгновенно. Кроме того, теплый старт и холодный старт, кажется, делают другое ... но опять-таки, это зависит от формы / окна. Поэтому, если я не прогрею Form1, производительность показа Form2 (в той же .NET dll) все еще будет низкой.

Я подключил мой отладчик VS .NET к процессу VB6 и обнаружил, что почти все 10 секунд тратится на внутренние компоненты .NET в ShowDialog (не в моем коде).

Проблема, по-видимому, одинаково присутствует как в WPF, так и в WinForms UI.

Любые идеи о том, как устранить эту проблему дальше?

Ответы [ 2 ]

0 голосов
/ 21 февраля 2012

Возможно ли, что другая деятельность происходит неявно? Вы упомянули, что это приложение WPF с автоматическим связыванием данных и все такое. Я бы предпринял следующие шаги:

  1. Включите SQL Profiler и посмотрите, выполняются ли какие-либо вызовы.
  2. Я бы запустил его через профилировщик Ants или встроенный и посмотрел, в чем проблема.
  3. Запустите ProcMon и посмотрите, к каким файлам осуществляется доступ.
  4. Посмотрите, можете ли вы собрать ngen. Проблема уходит? Если это так, то это может быть JIT-компилятор, хотя я сомневаюсь, что это так.

Я действительно не думаю, что проблема в Interop.

0 голосов
/ 21 февраля 2012

Я подозреваю, что почти все это задержка запуска CLR плюс задержки компиляции JIT.Разница здесь, вероятно, в том, что вы запускаете экземпляры JIT-компилятора по требованию и, возможно, даже дополнительные экземпляры CLR в процессе.

В процессе параллельно

...