У нас есть Word с надстройкой VSTO, которая занимает 20-30 секунд при первом запуске и 6-7 секунд при втором запуске. Это с Word 2007, .NET 3.5 и Windows XP. Word без надстройки потребовал около 5 секунд для холодного запуска и 2-3 для горячего запуска. В нашем холодном старте Word был первым приложением, запущенным после загрузки, и первым использованием любого кода .NET.
Как и вы, мы обнаружили, что время выполнения кода в надстройке не оказало заметного влияния на время загрузки. Использование VSTO означает, что .NET Framework и VSTO Runtime должны быть загружены и инициализированы. Падение скорости было связано с некоторой комбинацией издержек загрузки с диска и инициализации .NET / VSTO.
Конечно, первое «предложенное» решение состояло в том, чтобы незаметно запустить Word во время входа в систему, а затем завершить процесс Word, чтобы прогреть кэш диска. Конечно, это просто сделало машину не отвечающей на дополнительные 45 с лишним секунд во время загрузки (я думаю, потому что это увеличило конфликт дисков). Но, вау, Word запустился быстро после этого (если он был запущен вскоре после входа в систему). К счастью, мы не навязывали это решение нашим пользователям.
Мы также написали простое приложение .NET, которое будет просто запускаться, загружать некоторые из тех же зависимостей, что и наша надстройка Word, и завершать работу. Это также было бы запланировано во время входа в систему. Это потребовало нескольких секунд после запуска Word и добавило больше времени ко времени входа в систему, но было бессмысленно делать этот компромисс, когда некоторые пользователи могут даже не использовать Word во время их входа. сессия. В дополнение к бессмысленности, если они захотят использовать Word и запустят Word, как только настольный компьютер станет отзывчивым, тогда Word будет конкурировать за ресурсы с пользовательским приложением, которое должно было сгладить путь к нему!
Наша ситуация сложная, потому что у нас также есть надстройки для Word Template (VBA). Они также составляют значительную часть времени запуска, так как это вторая среда выполнения, которую необходимо инициализировать, и дополнительные файлы для загрузки из некоторых разбросанных областей диска. Переход от просто Word к Word с надстройкой VSTO или Word с надстройками VBA к Word вместе с надстройками VBA и VSTO дал нелинейное увеличение времени холодного запуска. То есть добавление большего количества зависимостей добавило больше времени загрузки к общему, чем время загрузки отдельной зависимости.
Мы также попробовали мастер COM shim. Использование COM Shim исключает время выполнения VSTO, но позволяет безопасно использовать .NET в надстройке. Было не слишком сложно преобразовать наш код VSTO для работы с сгенерированным COM Shim. Это значительно улучшило время загрузки (у меня нет цифр, я думаю, что оно вдвое сократило время холодного запуска, но это было с включенными надстройками VBA). Нашим идеальным решением было бы использовать COM Shim для загрузки надстройки .NET и перенести весь код VBA в .NET. Когда это решение было представлено внезапно, время холодного старта не было такой большой проблемой, как было задумано, и приоритет был понижен!