The gist of it is that you need to build Ruby with `RUBY_CONFIGURE_OPTS=--enable-yjit` true and verify it is enabled with `ruby --enable-yjit --version` and then finally run your code with `ruby --enable-yjit foo.rb`. For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

Thanks! Is there a "canonical" place to find this documented, like with the ruby distro?

> For Rails you'd want to just edit the executable Rails scripts like `bin/rails` to include that flag.

Alternately, you can edit your shell init scripts to put the correct thing in `RUBY_OPTS` ENV variable, yes?

I would consider this preferable to editing executable rails scripts with implementation-specific stuff (and then hoping that the app is always launched with those edited shell scripts, which I'm not sure eg `bundle exec rails` will do). I don't think editing Rails scripts is probably the "right" or recommended way to do this.

But I'm not going to try to specify what you put in `RUBY_OPTS` since i haven't done it myself and don't want to spread misinformation! (Again, is this documented in a centralized trustworthy place? As I try to google it... I am somewhat frustrated with the ruby documentation situation!)

Perhaps this is what you are looking for:

https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md

thank you!

We're using puma and set the RUBYOPT=--yjit in a systemd environment variable for our puma service.

The performance impact of enabling yjit was quite obvious in our charts. Another giveaway that it's properly enabled is the servers will use consume more memory.

You can also set RUBY_YJIT_ENABLE=1 to enable it.

That’s what I ended up using:

passenger_env_var RUBY_YJIT_ENABLE 1;

Also worth noting that the Ruby 3.2 Docker image can't run with YJIT yet, so if your production setup is in a container, it's most likely not using YJIT.

GitHub issue link here: https://github.com/docker-library/ruby/pull/398

That's not correct:

    $ podman run -it -e RUBYOPT="--yjit" ruby:3.2
    irb(main):001:0> puts RUBY_DESCRIPTION
    ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [aarch64-linux]
    => nil

It was supported immediately for Alpine based images because rustc 1.60+ was available in that distro.

Initially when 3.2 was released Debian based images didn't support it because Bullseye ships with a version of rustc that's too old to compile YJIT.

But https://github.com/docker-library/ruby/commit/6db728e addressed this a few days ago by installing a pre-compiled version of rustc straight from Rust and YJIT is available in Debian now.

You can confirm if it's available to use by running:

    $ docker container run --rm ruby:3.2.0-slim-bullseye ruby --enable-yjit -v
    ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [x86_64-linux]

If it weren't available then you would get an unknown argument error.

    $ docker container run --rm ruby:3.2.0-slim-bullseye ruby --enable-yjit -v
    ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [aarch64-linux]

Runs on Arm as well!

Yes, I'm pretty sure because:

1. Compiled with jyjit confrmed (ruby --yjit) returns the correct value

2. RubyVM::YJIT.enabled? returned true

I didn't notice any improvements at basically so I can't really say _for sure_ if it was working as intended.

RubyVM::YJIT.enabled? returning true does seem to settle it, and no need to say "pretty sure" with qualifications!