{"id":13265,"date":"2017-06-29T10:37:54","date_gmt":"2017-06-29T17:37:54","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/?p=13265"},"modified":"2021-09-30T10:08:16","modified_gmt":"2021-09-30T17:08:16","slug":"performance-improvements-in-ryujit-in-net-core-and-net-framework","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/performance-improvements-in-ryujit-in-net-core-and-net-framework\/","title":{"rendered":"Performance Improvements in RyuJIT in .NET Core and .NET Framework"},"content":{"rendered":"

RyuJIT is the just-in-time compiler used by .NET Core on x64 and now x86<\/a>\u00a0and by the .NET Framework on x64 to compile MSIL bytecode to native machine code when a managed assembly executes. I’d like to point out some of the past year’s improvements that have gone into RyuJIT, and how they make the generated code faster.<\/p>\n

What follows is by no means a comprehensive list of RyuJIT optimization improvements, but rather a few hand-picked examples that should make for a fun read and point to some of the issues and pull requests on GitHub that highlight the great community interactions and contributions that have helped shape this work. Be sure to also check out Stephen Toub’s recent post<\/a> about performance improvements in the runtime and base class libraries, if you haven’t already.<\/p>\n

This post will be comparing the performance of RyuJIT in .NET Framework 4.6.2 to its performance in .NET Core 2.0 and .NET Framework 4.7.1. Note that .NET Framework 4.7.1 has not yet shipped and I am using an early private build of the product. The same RyuJIT compiler sources are shared between .NET Core and .NET Framework, so the compiler changes discussed here are present in both .NET Core 2.0 and .NET Framework 4.7.1 builds.<\/p>\n

NOTE: Code examples included in this post use manual Stopwatch<\/code><\/a> invocations, with arbitrarily fixed iteration counts and no statistical analysis, as a zero-dependency way to corroborate known large performance deltas. The timings quoted below were collected on the same machine, with compared runs executed back-to-back, but even so it would be ill-advised to extrapolate quantitative results; they serve only to confirm that the optimizations improve the performance of the targeted code sequences rather than degrade it. Active performance work, of course, demands real benchmarking, which comes with a whole host of subtle issues that it is well worth taking a dependency to manage properly. Andrey Akinshin<\/a> recently wrote a great blog post<\/a> discussing this, using\u00a0the code snippets from Stephen’s post as examples. He will publish a follow-on post to this one with additional benchmarks soon. Thanks Andrey!<\/em><\/p>\n

<\/a>Devirtualization<\/h4>\n

The machine code sequence that the just-in-time compiler emits for a virtual call necessarily involves some degree of indirection, so that the correct target override method can be determined when the machine code executes. Compared to a direct call, this indirection imposes nontrivial overhead. RyuJIT can now identify that certain virtual call sites will always have one particular target override, and replace those virtual calls with direct ones. This avoids the overhead of the virtual indirection and, better still, allows inlining the callee method into the callsite, eliminating call overhead entirely and giving optimizations better insight into the effects of the code. This can happen when the target object has sealed type, or when its allocation site is immediately apparent and thus its exact type is known. This optimization was introduced to RyuJIT in dotnet\/coreclr #9230<\/a>; was subsequently improved by dotnet\/coreclr #10192<\/a>, dotnet\/coreclr #10432<\/a>, and dotnet\/coreclr #10471<\/a>; and has plenty more room for improvement<\/a>.\nThe PRs for the changes include some statistics (e.g. 7.3% of virtual calls in System.Private.CoreLib get devirtualized<\/a>) and real-world examples (e.g. this diff in ConcurrentStack.GetEnumerator()<\/code><\/a> — to see the code diff at that link you may have to scroll past the quoted output from jit-diff<\/code>, which is a tool<\/a> we use for assessing compiler change impact. It reports any code size increase as a “regression”, though in this case the code size increases are likely from enabling inlines, which is actually an improvement). Here’s a minimal example to illustrate the optimization in action:<\/p>\n