I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down qui

I've set this up in a staging environment of one of our apps to take a look. The staging environment we use for one-offs is on Heroku (can stand one up/down quickly), and the first issue is that a lot of the 'easy to deploy is a feature' PAAS platforms is that they bill by web/worker size restricted by memory rather than just pure virtual CPU power. Render etc all does this as well, and the memory headrooms are low. This means that you often have to deal with, say 512 MB per instance, and then if using something like Puma, have to work out how to split concurrency vs memory footprint. What I'm finding is that v3.2 YJIT loves memory, so I have to trade off that, which means less concurrency per process. Benchmarking it quickly, the 15% gains I might get on the thread aren't worth having to move to just 2 threads on a 512 MB instance versus the 3 threads I can get with YJIT not enabled. I think it's really neat and will continue to track it, but the performance in terms of memory trade-off isn't there quite as yet for our app profile. Not sure if others will find the same, but I guess its if their production environments aren't PAAS's with low memory headroom or not.