WPF медленно запускается на x64 в .NET Framework 4.0 - PullRequest
Новая
       21

WPF медленно запускается на x64 в .NET Framework 4.0

35 голосов
/ 01 июня 2010

Я заметил, что если я создаю свое приложение WPF для Any CPU / x64, требуется намного больше времени для запуска (порядка 20 секунд) или для загрузки новых элементов управления, чем при запуске на x86 (в выпуске) & режимы отладки, внутри или снаружи VS). Это происходит даже с простейшими приложениями WPF. Проблема обсуждается в этом потоке MSDN , но ответа там не было. Это происходит только с .NET 4.0 - в 3.5 SP1 x64 был так же быстр, как и x86. Интересно, что Microsoft, похоже, знает об этой проблеме, поскольку по умолчанию для нового проекта WPF в VS2010 используется x86.

Это настоящая ошибка или я просто ошибаюсь?

РЕДАКТИРОВАТЬ: Возможно, связано с этим: Время установки медленной привязки данных в C # .NET 4.0 . Я активно использую привязку данных.

1 Ответ

72 голосов
/ 01 июня 2010

На самом деле есть две основные причины, по которым тип проекта по умолчанию для приложений WPF - x86.

  • Отладка Intellitrace работает только с x86, и это выглядело бы очень плохо, если бы шаблоны проектов по умолчанию не работали с одной из их основных функций.
  • Многие разработчики до сих пор не знали о том, что их exe-файлы AnyCPU будут работать как x64 на 64-битных машинах, и были удивлены, обнаружив, что 32-битные библиотеки DLL, на которые они опирались, не существуют в 64-битных разновидностях, таких как драйверы OLEDB, некоторые родные DLL и т. Д.

Что касается проблем времени запуска, с которыми вы сталкиваетесь, то это похоже на проблему с NGEN. Поскольку для процессов x64 и x86 существуют разные кэши NGEN, может случиться так, что 64-битный кэш NGEN либо необходимо перестроить, либо обновить. Попробуйте запустить следующее из командной строки с повышенными привилегиями: 

CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319
NGEN update

Это команда для перекомпоновки собственных образов для сборок, которые уже помечены для NGEN. Также, вероятно, вам не поможет NGEN ваше приложение, если сборки не находятся в GAC, поэтому я бы не стал пытаться это сделать. Но сборки фреймворка, сборки инструментария и т. Д. Должны быть NGEN'd.

(Кстати, я получил несколько ошибок, когда выполнил указанную выше команду о сборках, которые не могли быть загружены. В основном это были сборки SQL и Visual Studio.)

...