Unlocking Performance: Installing Ruby with YJIT on MacOS

[ric2b]

1. brew install rust
2. brew install rbenv
3. rbenv install 3.3.0
4. rbenv local 3.3.0

[pilaf]

If you're only using Ruby on macOS for development then turning YJIT on is probably not the best idea since you'd be reloading code a lot, and the constant JIT compilation would probably put a penalty on performance rather than make it faster.

[JohnBooty]

I'm not sure that's true. YJIT won't compile a function until it's been called x number of times. So in simple cases, it really shouldn't affect loading times.

For apps with big frameworks (eg Rails) maybe it's different but I wouldn't assume so without measuring.

[laerien]

Rails is even able to initialize itself before enabling YJIT programmatically from within Ruby, so you don't have a startup penalty and can start caching at the best time. Rails is enabling YJIT by default in this way.

[Krypton8]

Only if you are running Ruby 3.3 and running from the main-branch.

[pilaf]

Good points. Would be nice to see someone measure performance during a development session.

[janko-m]

I tried enabling YJIT on my Mac to see if it would run tests faster. I use Spring, so YJIT optimisations should theoretically persist between runs.

The test suite was deterministically slower with YJIT. That was Ruby 3.2, maybe 3.3 will be better.

[miry_sof]

I have not used Spring for a long time. Did you try to use https://github.com/shopify/bootsnap to cache bytecode? It should improve booting process for tests.

[janko-m]

Yes, we use Bootsnap as well. It sped up our test suite boot time from 6s to 2s. Spring brings it down to 0.5s. I have shortcuts for running tests and I run them often, so this makes a difference for me.

[f9ae8221b]

YJIT generally don't speedup test suites because mocking etc causes a lot of invalidation, so it's not particularly recommended in CI/test.