In general it's not a big change. You should only turn on YJIT for long-running jobs -- the prod Rails server, plus probably background workers if you have them. YJIT does nothing unless you turn it on with the --yjit flag.
YJIT's going to affect memory usage, so it'll change your optimal number of processes and threads for your Rails server - play with it for your app specifically, because the percent speedup and mem expansion vary a lot from app to app. YJIT works fine with Puma and Webrick. I don't think anybody's tried it seriously with less-common servers like Falcon or Thin, but I'd expect it to work -- file a bug if it doesn't, because it should.
YJIT does speed up Rails - we're seeing about a 20%-25% speedup on little "hello, world" Rails apps (see: https://speed.yjit.org/), and about 11% on Discourse for a single thread. We don't have good multithreaded or multiprocess numbers yet, but it's in the works. YJIT scales with multiple threads/processes just like existing CRuby.
(All speed numbers are accurate as of right now, but may change over time.)
I would probably not use it in dev mode. While YJIT has pretty good warmup numbers, Rails throws away all existing application code for every request in dev mode. That's going to make YJIT a lot less useful. Play with it -- maybe I'm wrong for your app, especially if you use a lot of non-reloaded code (e.g. methods inside gems.) But I wouldn't expect great results in the development RAILS_ENV.
For deployment the short version is: add --yjit as a command line parameter in production mode and (probably) for your background workers. You can do this with "export RUBYOPT='--yjit'" or use your local preferred way.
Where I give weaselly-sounding qualifiers like "probably," that's because it can depend on your config. If you have plenty of memory but are often CPU-bound, YJIT is usually good. If you have really limited memory and your server CPUs are mostly idle, YJIT is usually bad. YJIT is also currently x86-only and runs on Mac and Linux but not Windows.
There has been a lot of historical demand for a Ruby config for servers: something that uses more memory to get faster operations, and that is optimised for long-running processes. YJIT is aimed directly at that. Non-JITted CRuby is mostly the opposite: fast startup, modest memory requirements, doesn't get significantly faster over time.
> YJIT works fine with Puma and Webrick. I don't think anybody's tried it seriously with less-common servers like Falcon or Thin, but I'd expect it to work -- file a bug if it doesn't, because it should.
Yes, it work fine with Unicorn, YJIT is currently serving a small portion of Shopify storefront traffic, and that app runs with Unicorn.
Of course since each of the unicorn process will generate its own executable code, the memory usage difference with Puma is even bigger, and copy on write can't help here.
Yeah, I was trying to come up with an idea for this. We try to eagerly load as much as we can before fork, so most of the memory is shared between the forked unicorns, but this won't work with YJIT right?
Ideally we would be able to eventually do the forks of a "mature" unicorn child an hour or so after all is JITed...
Because JITed code will inline things like the address of some specific objects (typically constants) etc. To share code between processes you'd need to ensure all these references are exactly the same in each process.
It may work a bit better now, but it's still very much not tuned for that. The result would probably still be slower than not JITting, for the same reasons mentioned for 2.6 in that link.
Nope, that's not what Bootsnap does. Bootsnap caches the pre-parsed .rb files as ISEQs (bytecode buffers.) It's conceptually a bit similar but not the same.
Weekly one-on-ones are pretty common in companies I've been part of, and GitHub has a lot of remote workers. Weekly one-on-ones seem more likely than not, in general.
Consider just-you personal retrospectives. Do them at the end of sprints or projects, and consider a weekly one. I do this both professionally and for personal stuff.
Where are you at geographically? I've never had good luck with the local recruiters in Silicon Valley, but maybe they're better in places with less info about market rates?
Recruiters are almost universally horrible, but there are usually a few out there in any market that have at least some idea what they're talking about. They are real diamonds in the rough and can take years to find, which makes them even more valuable.
However, sometimes even horrible recruiters can help you get a foot in the door somewhere. This is especially true with temping: you show up and start working right away with a minimal interview process. It's a great way to subvert corporate HR machines and get in the door and start making connections.
If you're looking for a new job of the type that recruiters may have, submit your resume to them and let them spam it out for you, but be firm with them when they want to waste your time by sending you to something that you know is a dead-end, or when they're trying to set up "check-ins" or other meetings that don't have a client/potential employer in attendance (do note that most will want to meet you once to look you over and make sure they won't be embarrassing themselves by sending you to an interview, but once the relationship is established, resist further recruiter-centric time waste).
