Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

YJIT tech lead here.

On the flip side, YJIT is probably one of the most memory-efficient JIT compilers out there (for any language). I say this having spoken to other JIT implementers.

We've worked really hard to reduce the memory overhead and at Shopify it's now down to less than 10% in our flagship production deployment.

Regardless, if memory usage is a legitimate concern for you, you can very easily remove the Rails initializer that turns on YJIT. You can choose between memory usage and response time. The choice is yours.



Oh yeah, please don't get me wrong. My original reply isn't to take away what YJIT accomplished. It was mainly to reference that in the past YJIT used more memory but maybe starting with Ruby 3.3 you won't have to think about that aspect anymore, even for apps running on a low spec machine.

I can't even begin to fathom at how much work and testing must have went into YJIT to make it work as well as it does. Thank you!


Is there a write up anywhere of the techniques employed to keep memory usage down that other implementations aren’t doing?


The article doesn't go into super deep details but we do touch on it in the paper we've recently published: https://dl.acm.org/doi/10.1145/3617651.3622982

And I went into some more details the talk I gave at RubyKaigi 2023: https://www.youtube.com/watch?v=X0JRhh8w_4I&t=2404s


I’m curious what you think the next big opportunities are to speed up Ruby?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: