Hacker News new | ask | show | jobs
by yebyen 2583 days ago
Yes, it's there, you can enable it, but I haven't heard anyone recommend it for production use, and it's not enabled by default. I tested it myself, it seemed to make my boring use case a little bit faster, once the JIT cache is initialized.
1 comments
chrisseaton 2583 days ago
> it seemed to make my boring use case a little bit faster

That's an unusual result - if it's faster for an actual app you're using in production you should report that as they'll be thrilled.

link
yebyen 2583 days ago
If you can call it that... my site is actually a Jekyll blog, in development mode, this is running in the most needlessly Ruby way. (A production deployment would have pre-rendered all the pages, and there wouldn't be a need to have a Ruby process even be present on the running server.)

Each visitor hits a Ruby process which renders the page directly, or serves it up from filesystem cache. I'm not honestly sure which, it could be monitoring the filesystem for changes to the markdown files, and only recompiling them when it observes a change on disk... or it could be rendering each request freshly for the visitor.

It would be hard-pressed to call this a production deployment though, I can say without a blog post or any hard data to back it up that when I did side-by-side trials, the page loading response times were marginally faster with the JIT enabled, after repeated trials.

After watching @tenderlove's talk from RailsConf 2019, I think I'm obligated to say also about this that, your results will improve if you paid attention to cache hit ratios, and consider tuning the JIT Cache size to achieve the maximum benefit. Perhaps these things will be better in a later iteration of Ruby JIT?

link