none
Framework 4.5 64 bit speed issue RRS feed

  • Question

  • Hi All

    I have been investigating a strange problem for a couple of days, and it has come to this:

    I have a simple WinForms applications with a lot of controls, and a lot of them nested in multi layer panels, TabControls etc. Constructed in VS 2012...

    There is no functionality on the form, the only thing that is happening is Loading the Controls in InitializeComponent.

    I build this application targeting FW4.0 and AnyCPU.

    Then I run it on a separate PC running Win7 Pro 64Bit, with only framework 4.0 installed.

    The initial load time of the form is approximately 2 seconds.

    Then I install Framework 4.5 on the machine, and reruns the application.

    Now the form load takes 25 seconds initially.

    Note: If I build the Application for x86 there is absolutely no problems. 

    I find this mighty strange, Framework4.5 should be backward compatible as far as I know. Is the install procedure for 4.5 missing some NGen routine for the dll's? Or is the Native Images somehow broken during this install?

    I know that 4.5 is an in place update of 4.0 so the dll's are visually identical, and that itself is a bit confusing....

    My own conclusion is to always target our WinfForms applications for x86, but still I really want to know what is going on.

    Any suggestions are much appreciated .

    Thanks in advance



    • Edited by _beaker Tuesday, December 17, 2013 7:16 AM
    • Moved by Mike DanesModerator Tuesday, December 17, 2013 7:30 AM JIT related
    Tuesday, December 17, 2013 7:16 AM

Answers

  • There have been similar reports before. Basically the x64 JIT compiler is having a hard time optimizing certain large methods such as InitializeComponent. In addition to using x86 instead of x64 you can try to turn of JIT optimizations for the InitializeComponent by applying it the following attribute:

    [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoOptimization)]

    In theory you could report this as a bug via the Connect site but the JIT team is already working on a new JIT compiler so there's little point in doing that: http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx

    • Marked as answer by _beaker Tuesday, December 17, 2013 8:28 AM
    Tuesday, December 17, 2013 7:35 AM
    Moderator
  • "By the way, could you please enlighten me about what this optimization really means and what the consequence of turning it of could be."

    The sole purpose of compiler optimizations is to make the code run faster. They are not supposed to affect the behavior of the code so adding that attribute shouldn't not affect the functionality in any way. And there's little to optimize in that method anyway, probably some of the control properties could be inline but it's unlikely that you'll get any measurable speed improvement in this particular case.

    • Marked as answer by _beaker Tuesday, December 17, 2013 8:28 AM
    Tuesday, December 17, 2013 8:25 AM
    Moderator

All replies

  • There have been similar reports before. Basically the x64 JIT compiler is having a hard time optimizing certain large methods such as InitializeComponent. In addition to using x86 instead of x64 you can try to turn of JIT optimizations for the InitializeComponent by applying it the following attribute:

    [System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoOptimization)]

    In theory you could report this as a bug via the Connect site but the JIT team is already working on a new JIT compiler so there's little point in doing that: http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx

    • Marked as answer by _beaker Tuesday, December 17, 2013 8:28 AM
    Tuesday, December 17, 2013 7:35 AM
    Moderator
  • Hi Mike

    Thank you very much for your helpful reply.

    That little trick really made quite a difference.

    We would prefer to target 4.5, but that is not an option since a number of our customers are using XP.

    By the way, could you please enlighten me about what this optimization really means and what the consequence of turning it of could be.

    Thanks again 

    Tuesday, December 17, 2013 7:58 AM
  • "By the way, could you please enlighten me about what this optimization really means and what the consequence of turning it of could be."

    The sole purpose of compiler optimizations is to make the code run faster. They are not supposed to affect the behavior of the code so adding that attribute shouldn't not affect the functionality in any way. And there's little to optimize in that method anyway, probably some of the control properties could be inline but it's unlikely that you'll get any measurable speed improvement in this particular case.

    • Marked as answer by _beaker Tuesday, December 17, 2013 8:28 AM
    Tuesday, December 17, 2013 8:25 AM
    Moderator
  • Thanks a lot Mike :)
    Tuesday, December 17, 2013 8:28 AM
  • I have also seen this problem.  Turning off optimizations over all corrects the issue.  Turning off optimizations for the InitializeComponent corrects the issue.  Changing the X86 also corrects the issue.

    Everything works fine on the 4.0 framework.  The 4.5 framework introduced this problem.

    I did file a report on Microsoft Connect - https://connect.microsoft.com/VisualStudio/feedback/details/807888/upgrading-to-the-4-5-framework-causes-x64-applications-to-load-slowly

    Microsoft has not replied to my report of the problem.


    Danny

    Wednesday, February 5, 2014 2:32 PM