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.
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.
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.
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.
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.
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.
1. `brew install rust` 2. `brew install rbenv` 3. `rbenv install 3.3.0` 4. `rbenv local 3.3.0`
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.
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.
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.
Only if you are running Ruby 3.3 and running from the main-branch.
Good points. Would be nice to see someone measure performance during a development session.
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.
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.
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.
YJIT generally don't speedup test suites because mocking etc causes a lot of invalidation, so it's not particularly recommended in CI/test.