.Net 3.5 Приложение Windows Forms: время загрузки x86 и x64 в 64-битной Vista
Мы разрабатываем приложение Winforms и оптимизируем время запуска.
Приложение работает на 64-битных машинах Vista. В нашем тестировании мы обнаружили противоречивый результат. При прочих равных, ориентация на 32-битные и 64-битные нагрузки вдвое меньше. Может ли кто-нибудь пролить свет на то, почему?
Спасибо.
[Редактировать] Мы развертываем приложение через ClickOnce, который, согласно нашим исследованиям, запускает приложения в уникальной песочнице. Поэтому он всегда запускается из холодного состояния, поэтому попытки улучшить производительность здесь были бесплодны.
Нашей основной проблемой было наличие в проекте 32-битных dll. Как только мы нацелили проект на x86 (хотя он работает на x64), время загрузки сократилось вдвое. [/Редактировать]
Ответы 3
64-разрядная версия обычно использует вдвое больше памяти в куче: каждый указатель занимает в два раза больше места, а .NET полна указателей. Поскольку на запуск сильно влияет инициализация памяти, это может составлять часть дополнительных накладных расходов. См. Также Пламя Дональда Кнута о 64-битных указателях.
Обратите внимание, что, по словам Microsoft, .Net 3.5 SP1 включает значительную часть работы по повышению производительности при запуске (улучшение до 40% для некоторых приложений), так что вы можете увидеть, помогает ли это вообще.
.NET 3.5 SP1 получает улучшенную производительность при запуске, поскольку больше не проверяется строгое имя сборок, поступающих из надежных расположений. Немного спорным в моей книге, но несколько оправданно.
Я проверил, обходит ли 64-разрядная версия CLR этот трудоемкий этап. Подписал DLL, поместил в GAC, затем пропатчил байт. При загрузке сборки претензий нет. Таким образом, разница не объясняется улучшением параметров запуска SP1.
Другие факторы, влияющие на время запуска: - Загрузка CLR с диска (только холодный старт) - Расправы по зависимым узлам - JIT-компиляция кода запуска
Холодный старт вполне может быть фактором, у вас, вероятно, нет других запущенных процессов с загруженной 64-битной версией CLR. Легко устранить, запустив фиктивное приложение .NET во время тестирования.
По той же причине сборка может занять больше времени. Маловероятно, что 64-битные ngen-ed образы сборок .NET находятся в кеше файловой системы. Опять же, это легко устранить с помощью фиктивного приложения, зависящего от тех же сборок.
64-битный JITter - более крепкий орешек. Произвольный вызов состоит в том, чтобы предположить, что MSFT не потратил столько времени на выполнение этой задачи, сколько 32-битный JITter. Однако ничего не подтверждено никакими доказательствами. Трудно также измерить, вам нужно загрузить сборку с помощью Assembly.Load, а затем использовать Activator.CreateInstance (), когда конструктор класса вызывает как можно больше кода.