WPF lento para iniciar en x64 en .NET Framework 4.0

Question

Me he dado cuenta de que si construyo mi aplicación WPF para Cualquier CPU/x64, se necesita MUCHO más para iniciar (del orden de unos 20 segundos) o para cargar nueva controles que si se inició en x86 (en la versión & modos de depuración, dentro o fuera de VS). Esto ocurre incluso con las aplicaciones WPF más simples. El problema se discute en this MSDN thread, pero no se proporcionó ninguna respuesta allí. Esto sucede solo con .NET 4.0: en 3.5 SP1, x64 fue tan rápido como x86. Curiosamente, Microsoft parece saber acerca de este problema ya que el valor predeterminado para un nuevo proyecto de WPF en VS2010 es x86.

¿Es esto un error real o simplemente lo estoy haciendo mal?

EDIT: Posiblemente relacionado con esto: Slow Databinding setup time in C# .NET 4.0. Estoy utilizando datos vinculantes en gran medida.

Answer 1

En realidad, hay 2 razones principales por las que el tipo de proyecto predeterminado para las aplicaciones WPF es x86.

• Intellitrace depuración sólo funciona con x86 y que se vería muy mal si las plantillas de proyecto por defecto no trabajan con una de sus características estrella.
• Muchos desarrolladores todavía no eran conscientes del hecho de que sus ejecutables AnyCPU se ejecutarían como x64 en máquinas de 64 bits y se sorprendieron al descubrir que las DLL de 32 bits en las que confiaban no existían en las variedades de 64 bits como los controladores OLEDB, ciertos nativos DLL, etc.

En cuanto a los problemas de tiempo de inicio que está experimentando, casi parece un problema con NGEN. Dado que existen cachés NGEN diferentes para procesos x64 y x86, es posible que el caché NGEN de 64 bits necesite ser reconstruido o actualizado. Pruebe a ejecutar lo siguiente desde un símbolo del sistema elevado:

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

Este es el comando para reconstruir imágenes nativas para los conjuntos que ya se han marcado para NGEN. Probablemente tampoco le hará ningún bien a NGEN su aplicación si las asambleas no están también en el GAC así que no me molestaría en tratar de hacer eso. Pero las asambleas marco, conjuntos de herramientas, etc. deben ser NGEN'd.

(Por cierto, me hizo llegar varios errores cuando me encontré con el comando anterior sobre los ensamblados que no se pudo cargar. Estaba en su mayoría SQL y Visual Studio asambleas.)