.NET 3.5 Приложение Windows Forms: время загрузки x86 и x64 в 64-битной Vista

Question

Мы разрабатываем приложение Winforms и оптимизируем время запуска.

Приложение работает на 64-битных компьютерах Vista. В нашем тестировании мы обнаружили что-то вроде противоречивого результата. При прочих равных, на 32-битную и 64-битную загрузку можно рассчитывать вдвое быстрее. Кто-нибудь может пролить свет на то, почему?

Спасибо.

[Изменить] Мы разворачиваем приложение через ClickOnce, которое, в результате нашего исследования, запускает приложения в уникальной песочнице. Поэтому он всегда начинается с нуля, поэтому стремление улучшить производительность здесь было бесплодным.

Нашей главной проблемой было наличие 32-битных библиотек в проекте. Как только мы нацелили проект на x86 (хотя он и работает на x64), время загрузки сократилось вдвое. [/ Edit]

Answer 1

.NET 3.5 SP1 получает улучшенную производительность при запуске, больше не проверяя строгое имя сборок, которые поступают из надежных расположений. Немного спорный в моей книге, но несколько оправданы.

Я проверил, обходит ли 64-битная версия CLR этот трудоемкий этап. Подписал DLL, поместил ее в GAC, затем пропатчил байт. Никаких нареканий при загрузке сборки. Таким образом, разница не в улучшении запуска SP1.

Другие факторы во время запуска: - Загрузка CLR с диска (только холодный старт) - унижение для зависимых сборок - JIT компилирует код запуска

Coldstart вполне может быть фактором, вероятно, у вас не запущены другие процессы, на которых загружена 64-битная версия CLR. Легко устранить, запустив фиктивное приложение .NET во время теста.

По той же причине может потребоваться больше времени для сборки. Маловероятно, что 64-битные ngen-редактированные образы сборок .NET находятся в кеше файловой системы. Опять же, легко устранить с помощью фиктивного приложения, имеющего зависимость от одних и тех же сборок.

64-битный JITter - более крепкий орешек. Произвольный вызов состоит в том, чтобы предположить, что MSFT не тратит столько времени на выполнение этого одного исполнения, как 32-битный JITter. Ничто не подкреплено никакими доказательствами. Также сложно измерить, вам нужно будет загрузить сборку с помощью Assembly.Load, а затем активировать Activator.CreateInstance (), где конструктор класса вызывает как можно больше кода.

Answer 2

64-битная версия обычно использует вдвое больше памяти в куче: каждый указатель занимает вдвое больше места, а .NET полон указателей. Поскольку запуск сильно зависит от инициализации памяти, это может составлять часть дополнительных издержек. См. Также Пламя Дональда Кнута о 64-битных указателях .

Answer 3

Обратите внимание, что, согласно Microsoft, в .Net 3.5 SP1 была включена значительная часть работы по повышению производительности при запуске (до 40% улучшения для некоторых приложений), поэтому вы можете посмотреть, поможет ли это вообще.