So that backs up my hunch above.
It also means it doesn’t only interest Rubyist but pretty much all developers. Even if I don’t have high hopes, publicizing this on popular places such as HN might actually lead to something long term. But yes, I agree that this isn’t something you can do now and wait on.
I tried several variations of that a few years back when I was working on bootscale (bootsnap’s father), but there are many problems I didn’t find a solutions to. Out of the top of my mind changing the code path mean you need to rewrite all __FILE__, __LINE__ and dependant calls such as require_relative etc.
However what we can do much more easily to get most of gain with little effort is to store the Bootsnap iseq in a giant indexed file. Because anyway, after your first boot you’re no longer reading the ruby source file, but the bootsnap cache.
We just need to have an efficient way to keep a big mmaped hash opened. Something like this: GitHub - luispedro/diskhash: Diskbased (persistent) hashtable