Someone else pointed the same thing on bluesky, so I guess this part of my post isn't very clear. First, I/O bound isn't necessarily a very well defined term,

Someone else pointed the same thing on bluesky, so I guess this part of my post isn't very clear. First, I/O bound isn't necessarily a very well defined term, but generally speaking, it implies that you can't substantially speedup such system by speeding up code execution. The fact that YJIT did yield substantial performance improvement in the real world suggest many Rails apps aren't in fact strictly I/O bound. Now about the 15-30% vs 2-3x, what I mean by that is the benchmark where YJIT yield this much are mostly micro-benchmarks, on more complex and heterogenous code, the gains are much smaller, hence we can assume the "Ruby" part of these applications wasn't improved by this much. So for YJIT to be able to yield `15-30%` latency gains, this latency must have been in large part composed of Ruby execution. One last thing to note is that YJIT can only speedup pure Ruby code, in a Rails application, a large part of the CPU time isn't in pure Ruby code, but in various methods implemented in C that YJIT can't speedup. Ultimately the lobste.rs maintainer kindly offered to run an experiment in production, so we should soon see if my assumptions hold true or if I was way off, at least for that particular app: https://github.com/lobsters/lobsters/pull/1442 https://github.com/lobsters/lobsters/pull/1442 Edit: > Instead of guessing if the DB is performing badly by looking at Rails That isn't really the topic though. The question is more about how much Ruby's GVL is actually released, and its implications.