Shopify deploys YJIT on business-critical services in production, such as Storefront Renderer, the software that powers all online storefronts on Shopify’s platform, and Shopify’s Monolith. As of the Ruby 3.2 release, YJIT sped up our Storefront Renderer by 10% on average.
Storefront Renderer is a complex application. Your more reasonable-sized app might get better/worse results. Here are some other YJIT performance results in production outside Shopify:
We sometimes hear people say YJIT doesn’t speed up their application or uses too much memory. The following documentation covers some tips for tuning YJIT in such cases.
Monitoring YJIT in Production might also help you get more insight.
Ruby 3.3.0-preview2 has been released on Sep 14th, 2023. We compared the performance of Ruby 3.2 YJIT, Ruby 3.3-preview2 YJIT, and Ruby 3.3-preview2 interpreter on the Storefront Renderer. It’s a large-scale service with the following properties:
We deployed Ruby 3.2.2 YJIT and Ruby 3.3.0-preview2 YJIT to different clusters that receive an equal amount of traffic. We compared their response times in a 24-hour window on a weekday.
The numbers and the graph show Ruby 3.3.0-preview2 YJIT’s average/p50/p90/p99 response time speedup ratio over Ruby 3.2.2 YJIT’s. Higher is better for Ruby 3.3.0-preview2 YJIT.
This shows that Ruby 3.3.0-preview2 YJIT is 13% faster than Ruby 3.2.2 YJIT on average. If you’re using Ruby 3.2 YJIT, upgrading Ruby to 3.3 should give you a 13% speedup.
During the same 24-hour window, we also deployed Ruby 3.3.0-preview2 interpreter to another cluster. We compared its performance against that of the cluster with Ruby 3.3.0-preview2 YJIT.
The numbers and the graph show Ruby 3.3.0-preview2 YJIT’s average/p50/p90/p99 response time speedup ratio over Ruby 3.3.0-preview2 interpreter’s. Higher is better for Ruby 3.3.0-preview2 YJIT.
When you run Ruby 3.3 interpreter, just enabling YJIT will give you a 15% speedup.
The CRuby interpreter writes and reads temporary values on memory. Ruby 3.2 YJIT used to work in the same way for compatibility reasons, but Ruby 3.3 YJIT is able to allocate registers to those operations. In general, accessing CPU registers is much faster than communicating with memory, so Ruby code runs faster with the optimization.
Ruby 3.3 YJIT supports compiling more kinds of Ruby code than Ruby 3.2 YJIT.
When a method has optional arguments, Ruby 3.2 YJIT compiles only one combination of parameter precenses,
but Ruby 3.3 YJIT handles multiple combinations.
Ruby 3.2 YJIT does not compile code that is executed after
but Ruby 3.3 YJIT does.
Ruby 3.2 YJIT gives up compiling a method call when it does not support the method call type,
but Ruby 3.3 YJIT falls back to an implementation that can handle anything.
In a nutshell, more code runs on JIT with Ruby 3.3 YJIT than Ruby 3.2 YJIT, so it’s faster.
Since Ruby 3.3.0-preview2 YJIT generates more code than Ruby 3.2.2 YJIT, this can result in YJIT having a higher memory overlead. We put a lot of effort into making metadata more space-efficient, but it still uses more memory than Ruby 3.2.2 YJIT. We’re looking into skipping compilation of paths that are less frequently executed.
Ruby’s method calls are complex. YJIT code spends a lot of time bookkeeping frames for method calls. We’re working on making any method calls faster by packing frame metadata into a single pointer and lazily materializing its fields when necessary. Hopefully, it will greatly speed up method calls as well as reducing the code size.
Ruby 3.2 YJIT has optimized the production workloads of Shopify and other companies. We encourage you to enable YJIT in production. Once Ruby 3.3 is released, it should make your application even faster.
This document explains how to enable YJIT. As a reminder, the following links may help you troubleshoot performance problems with YJIT.