3

I am trying to investigate a performance problem where an application runs slowly when run in 64bit on one of our servers, while it runs fast in 32 bit on that same machine or 64 bit anywhere else.

I have seen that this could be related to the JIT compiler being used. Is there a way I can tell which JIT compiler is being used to run my application? I'd like to see if it's different on the server than on the other computers where the 64 bit version works fine.

edeboursetty
  • 5,669
  • 2
  • 40
  • 67
  • I doubt that your performance problem is coming from JIT compiler, better check your code and try to refactor it and don't lose time. – mybirthname Oct 03 '16 at 15:00
  • Not sure how to tell which one is active, but you should certainly try [enabling/disabling RyuJIT](https://github.com/Microsoft/dotnet/blob/master/docs/testing-with-ryujit.md) explicitly and compare performance. It's had some bugs, so it could conceivably have performance issues. – Roman Starkov Oct 03 '16 at 15:01
  • 1
    This might be a useful link. [Where exactly is .NET Runtime (CLR), JIT Compiler located?](http://stackoverflow.com/questions/30802270/where-exactly-is-net-runtime-clr-jit-compiler-located) You could look at the DLL file versions on each server to see if there is a difference. I'm not sure if this is the location of the RyuJIT 64bit compiler though. – Jason Evans Oct 03 '16 at 15:18
  • Related to [How do I verify that ryujit is jitting my app?](http://stackoverflow.com/q/22422021/102351) – Scorpion Oct 03 '16 at 15:22
  • 1
    Based on my (biased) experience I suspect a more obvious environmental issue with that one specific server. It could be anything from a different subnet, slow DNS server there or a new virus scanner engine update which was bad or an old .NET install. To find that out you should profile your application on that server. Otherwise you will most probably never find the root cause since there are so many possibilities to make your application slow. One possibility is a .NET 4.6.0 install which has a GC performance bug. See https://aloiskraus.wordpress.com/2016/07/31/when-known-net-bugs-bite-you/ – Alois Kraus Oct 03 '16 at 15:27
  • Thanks for the halpful comments – edeboursetty Oct 03 '16 at 15:31
  • If you want to determine JIT version in runtime, you could use the following hack: http://aakinshin.net/en/blog/dotnet/jit-version-determining-in-runtime/ – AndreyAkinshin Oct 07 '16 at 10:07

2 Answers2

1

JIT Version

You can follow Hans' steps to verify that RyuJIT is loaded into your application. [2]

use the debugger to ensure you have the new version. First have a look-see at the runtime directory with Explorer, navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319. You'll find the the two jitters there, clrjit.dll is new jitter based on the Ryujit project and compatjit.dll is the legacy x64 jitter.

Project > Properties > Debug > tick the "Enable native code debugging option". Use the Build tab and ensure you've removed the jitter forcing, the "Prefer 32-bit" option must be unticked, "Platform target" must be set to AnyCPU. And use the Application tab to pick the framework target.

Use Debug > Step Into to start debugging. Debug > Windows > Modules displays the list of loaded modules. Find the jitter DLLs back in that list, click the "Name" column header to sort by name. If you see compatjit.dll back then you are using the legacy jitter. Do note that you'll always see clrjit.dll, they both get loaded when the legacy jitter is used.

[2] https://stackoverflow.com/a/31534544/102351


JIT Architecture

You can determine the architecture of the JIT used by checking whether the running application is a 64-bit process or not.

Environment.Is64BitProcess

https://msdn.microsoft.com/en-us/library/system.environment.is64bitprocess.aspx

This property is implemented as a direct true/false return within the 64-bit and 32-bit versions of mscorlib, respectively. [1]

[1] https://stackoverflow.com/a/1913908

Community
  • 1
  • 1
Scorpion
  • 784
  • 7
  • 25
  • What do you think "JIT" means? – CodeCaster Oct 03 '16 at 15:04
  • Based on their question, they're asking how to detect whether the x86 or x64 JIT is used in their process. The Environment.Is64BitProcess property can determine this, since it's hardcoded as a true/false depending on the architecture of the loaded mscorlib. – Scorpion Oct 03 '16 at 15:06
  • 1
    No, the OP claims the application runs fast on all but one server in 64-bit, so they want to see if the JIT compiler version differs on that server. Your answer also makes it sound like "JIT" equals "bitness". – CodeCaster Oct 03 '16 at 15:09
  • Noted, I've edited it to make it more clear that the original answer was only referring to the architecture of the jitter used. – Scorpion Oct 03 '16 at 15:23
1

Use the JIT performance counters (https://msdn.microsoft.com/en-us/library/w8f5kw2e(v=vs.110).aspx#jit) to monitor when code is being jitted.

You can use ngen (https://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx) to improve application start-up time by removing the need to JIT code - ngen pre-compiles assemblies into native images.

Polyfun
  • 9,479
  • 4
  • 31
  • 39