Hacker News Reader

Comment by igravious | Hacker News Reader

It's unorthodox I'll give you that. When I think JIT I don't think "generates C code and hands that to a C compiler"!

However. Let's look at this dispassionately. This is only enabled if you use the --jit option. This means that this option can be switched on for production runs and not for dev and test modes. That seems like a very easy switch to flick.

Also, from reading the pages @petercooper linked to it seems the infrastructure is pretty non-invasive so far and leverages a lot of the existing infrastructure. Bugs have been squashed and all tests are passing.

I'm excited to try this on my own machine and see how it compares to 2.5 w/ Bootsnap, as I've posted here before I'm itching to drop Bootsnap.

View on HN

Well, Bootsnap only aim at speeding up code loading / boot, whereas the author of the JIT talks about something like 6 time slower boot, so I don't really see the relation between the two.

Also since I'm somewhat part of the Bootsnap creation, I'd be very interested to know why you're itching to remove it.

Hey thanks for informing me.

If Bootsnap is an opt cache I'm all for it. If it's some sort of `require' and `require_relative' hackage black-magic jiggery pokery then no.

I already ran into issues with my own app where I encountered a slight glitch because of Bootsnap. Bootsnap needs to be 100% bullet-proof before I go near it.

I hate all these optimizations like Spring and Bootsnap and Turbolinks that only end up causing headaches and are yet another thing you have to reason about if something is going wrong. Simpler is better. Less moving parts is better.

Now of the three: Spring and Bootsnap and Turbolinks–probably Bootsnap is the closest to being deployable with 0% hassle. I wouldn't touch Turbolinks with a 10 foot barge pole. Yet another recent confirmation of the wisdom of that decision for me is that it messes with Vue.js. No Turbolinks, no problem.

If Bootsnap and MJIT are more or less orthogonal then yay. There is startup time and execution time. Improving both would be awesome.

> If Bootsnap is an opt cache I'm all for it.

It does integrate with the ISeq API in recent MRIs to acts as an opt-cache yes. It's not what brings most of the performance gain though.

> If it's some sort of `require' and `require_relative' hackage black-magic jiggery pokery then no.

Well, there is no black magic, it's computers, they are machines, not magicians. And yes it's mostly what Bootsnap (and bootscale before it) does.

> Bootsnap needs to be 100% bullet-proof before I go near it.

The thing is it can't. There is a couple corner cases in Ruby's require semantic that just can't be replicated. So yeah, there is about a few dozen obscure gems out there that will break if used with Bootsnap, but for the vast majority of projects it's gonna be a drop in boot time gain without any headache.

We use bootsnap for the development more of our rails Backend / Monolith and it's a breeze for startup especially when running single tests locally. I have never experienced any issues since we introduced it last autumn.

It will not help too much for production or testing environments if you do not have specific timing requirements on startup.

It's a completely different type of shoe compared to things like spring which will result in a world of pain in specific situations if you're not constantly aware of what it does.

Reply on news.ycombinator.com