Измерение производительности запуска приложения c # - PullRequest
0 голосов
/ 10 июня 2011

Я заметил, что иногда .net 4.0 c # приложение запускается долго, без какой-либо видимой причины. Можно ли определить, что на самом деле происходит, какие модули загружены? Я использую ряд внешних сборок. Может ли помещение их в GAC улучшить производительность?

.NET 4 медленнее, чем .NET 2?

Ответы [ 3 ]

4 голосов
/ 10 июня 2011

.NET-программы имеют два разных способа запуска.Их называют холодным стартом и горячим стартом.Холодный запуск - медленный, вы получите его, когда ни одна из программ .NET не запускалась раньше.Или когда программа, которую вы запускаете, велика и никогда не запускалась раньше.Операционная система должна найти файлы сборки на диске, они не будут доступны в кеше файловой системы (RAM).Это занимает некоторое время, жесткие диски работают медленно, и есть много файлов для поиска.Небольшое бесполезное приложение Winforms должно загрузить 51 DLL для начала работы.Ничего не стоящее приложение WPF весит 77 DLL.

Вы получаете теплый старт, когда файлы сборок были загружены раньше, не так давно.Данные файла сборки теперь поступают из оперативной памяти, а не с медленного диска, это zipedy-doodah.Единственные накладные расходы при запуске - это дрожание.

Мало что можно сделать с холодным запуском, сборки должны приходить с диска так или иначе.Быстрый диск имеет большое значение, SSD особенно эффективны.Использование ngen.exe для предварительной сборки сборки на самом деле усугубляет проблему, создает другой файл, который необходимо найти и загрузить.По этой причине Microsoft рекомендует , а не , предваряя небольшие сборки.Видение этой проблемы с программами .NET 4 также очень важно, у вас не так много программ, которые связаны с CLR версии 4 и сборками фреймворка.Во всяком случае, пока, это не решается со временем.

Есть еще один способ, которым эта проблема автоматически исчезает.Функция Windows SuperFetch начнет замечать, что вы часто загружаете CLR и сопряженные сборки Framework, и начинает автоматически загружать их в RAM.Тот же трюк, который используют «оптимизаторы» Microsoft Office и Adobe Reader.Это также программы, которые имеют много зависимостей DLL.Неуправляемые, проблема не характерна для .NET.Эти оптимизаторы являются грубыми, они предварительно загружают библиотеки DLL при входе в систему.Это подход «я действительно важен, вверните все остальное» для решения проблемы, убедитесь, что вы отключили их, чтобы они не вытесняли пространство ОЗУ, которое мог бы использовать SuperFetch.

1 голос
/ 10 июня 2011

Время запуска, скорее всего, связано с компиляцией сборки JIT во время выполнения в машинный код для выполнения. На него также может повлиять отладчик - как предложил другой отвечающий.

Исключая это - я расскажу о приложении, запущенном «в дикой природе» на компьютере пользователя, без отладчика и т. Д.

JIT-компилятор в .Net 4, я думаю, будет справедливо сказать, лучше, чем в .Net 2 - так что нет; это не медленнее.

Вы можете значительно улучшить время запуска, запустив ngen на сборках вашего приложения - это предварительно компилирует EXE и DLL в собственные образы. Однако при этом вы теряете некоторую гибкость, и, в общем, нет особого смысла.

Вы должны увидеть время запуска некоторых приложений MFC, написанных на C ++ - весь нативный код, но в зависимости от того, как они связаны, они могут занять столько же времени.

Конечно, это также зависит от того, что приложение делает при запуске!

0 голосов
/ 10 июня 2011

Я не думаю, что размещение ваших сборок в GAC будет загружать производительность. Если возможно, ведите журнал для каждой инструкции, которую вы написали о событиях Загрузка или Intialize, что может помочь вам определить, какое утверждение на самом деле занимает время, и с этим вы можете определить библиотеку, которая занимает время при загрузке.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...