WPF slow to start on x64 in .NET Framework 4.0

Question

I've noticed that if I build my WPF application for Any CPU/x64, it takes MUCH longer to start (on the order of about 20 seconds) or to load new controls than it does if started on x86 (in release & debug modes, inside or outside of VS). This occurs with even the simplest WPF apps. The problem is discussed in this MSDN thread, but no answer was provided there. This happens only with .NET 4.0 -- in 3.5 SP1, x64 was just as fast as x86. Interestingly, Microsoft seems to know about this problem since the default for a new WPF project in VS2010 is x86.

Is this a real bug or am I just doing it wrong?

EDIT: Possibly related to this: Slow Databinding setup time in C# .NET 4.0. I'm using data binding heavily.

Answer 1

Actually there's 2 main reasons that the default project type for WPF applications is x86.

• Intellitrace debugging only works with x86 and that would look pretty bad if the default project templates didn't work with one of their star features.
• Many developers were still not aware of the fact that their AnyCPU exe's would run as x64 on 64 bit machines and were surprised to find that 32 bit DLL's they relied on did not exist in 64 bit varieties such as OLEDB drivers, certain native DLL's, etc.

As for the startup time issues you're experiencing, it almost seems like an issue with NGEN. Since there are different NGEN caches for x64 and x86 processes, it could be that the 64 bit NGEN cache either needs to be rebuilt or updated. Try running the following from an elevated command prompt:

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

This is the command to re-build native images for assemblies that have already been marked for NGEN. It also probably won't do you any good to NGEN your application if the assemblies are not also in the GAC so I wouldn't bother trying to do that. But framework assemblies, toolkit assemblies, etc should all be NGEN'd.

(By the way, I did get several errors when I ran the above command about assemblies that could not be loaded. It was mostly SQL and Visual Studio assemblies.)