Оптимизиране на стартирането на приложението

Написано на 13 февруари 2009 г. Публикувано в .NET Framework

СЪДЪРЖАНИЕ

Стартирането на приложения обикновено се класифицира като студено или горещо. Студеното стартиране в контекста на управлявано приложение означава, че нито системните сглобки на Microsoft® .NET Framework, нито кодът на приложението се зареждат в паметта и трябва да бъдат извлечени от диска. Горещият старт е или последващо стартиране на приложението, или стартиране на приложението в случай, че по-голямата част от системния код вече е в паметта, тъй като преди това е бил използван от друго управлявано приложение.

Студен старт

В повечето случаи студеният старт зависи от I/O. С други думи, при изчакване на данни минава повече време, отколкото при обработка на инструкции. Времето за стартиране на приложението е равно на времето, необходимо на операционната система за получаване на кода от диска, плюс времето, необходимо за извършване на допълнителна обработка, като например JIT компилиране на IL код или друга инициализация, която се извършва при стартиране на приложението. Тъй като обработката обикновено не е ограничителният етап на студен старт, основната цел на всяко изследване за ускоряване на стартирането на приложението е да се намали достъпът до диска чрез намаляване на количеството на заредения код.

Начинът на писане на кода на приложението също оказва значително влияние върху студения старт, така че е важно да разберете дали приложението отваря допълнителни файлове или стартира други процеси, които могат да се конкурират за I/O ресурси при стартиране.

Тъй като студеното стартиране е I/O зависим сценарий, използването на обикновен CPU профилист (както базиран на инструменти, така и базиран на проби) няма да помогне за проучването. Базираните на инструменти профилари показват времето, прекарано в изчакване на I/O като блокирано. Проблемът е, че дори ако успеете да съпоставите блокираното време с определен стек разговори, то се отчита само веднъж. Всяко последващо дисково I/O се игнорира, така че получавате непълна картина на въздействието на дисковите I/O върху общото време за изпълнение.

При базирани на извадка профилисти събраната информация може дори да навреди. Използването на процесора се проследява тук, а не I/O, така че цялото I/O време изобщо не се отчита в отчетите за профилиране.

На фиг. 1, можете сами да се убедите, че студеният старт зависи от I/O, като стартирате приложението си два пъти подред. Първото изпълнение най-вероятно ще бъде значително по-бавно от второто (при което по-голямата част от изпълнимия код вече е в паметта след първото изпълнение, което спестява време при достъп до диска). Разбира се, за да бъде първото стартиране наистина студено, първо трябва да рестартирате компютъра си, да се уверите, че в стартовата папка няма управлявани приложения и че никоя услуга на Windows®, която използва управляван код, не се стартира, когато потребителят влезе.

Фигура 1 Време за четене на диска и време за студен старт на процесора

Имайте предвид, че за идеален тест за студен старт бихте деактивирали услугата SuperFetch, която може да зареди предварително част от кода за вашето приложение, като осигури по-топъл скрипт за стартиране. Измерванията с деактивиран SuperFetch позволяват да се изчисли, че целият код на приложението се зарежда в паметта при стартиране на приложението, така че разходите за I/O могат да бъдат оценени по-точно. Трябва да се помни обаче, че не измервате точно какво ще получи потребителят, така че не е необходимо да правите окончателни заключения относно ефективността на приложението въз основа на данните, събрани с изключен SuperFetch.

Два брояча на производителността, които можете да използвате за измерване на I/O въздействието на студен старт, са% cpu време и% време за четене на диска. Ако I/O е от решаващо значение за стартиране, което се очаква, ще има голяма разлика между% използване на процесора и време за четене на диска. Можете да събирате броячи на производителността с помощта на PerfMon (вижте страничната лента на Launch Speed Materials за повече подробности).

На фиг. 1, червената линия представлява% време за четене от диска, а зелената линия представлява% използване на процесора. Студеният старт показва малко използване на процесора в сравнение с времето за четене на диска.

Когато приложението се рестартира, има скрипт за горещо стартиране, така че броячът на производителността трябва да показва различна картина. На фиг. 2 процес зависи от процесора. Можете да видите, че% от времето за четене на диска е много по-ниско от% от използването на процесора.

Фигура: 2 Горещият старт отнема по-малко време

Горещият старт е свързан с процесора, защото кодът вече е в паметта (и не са необходими допълнителни I/O), но кодът трябва да бъде компилиран JIT, преди да стартирате приложението. Днес генерираният от JIT собствен код в .NET Framework не се запазва от едно изпълнение на друго приложение.

Ако горещото стартиране не е значително по-бързо от студеното, трябва да разберете какво зарежда процесора (тъй като по време на горещо стартиране по-голямата част от кода е вече заредена и зависимостта от I/O е малко вероятно). Причината трябва да се крие или в голямото количество JIT-компилиран код, или в сложните изчисления, които приложението извършва.