Multithreading in Lua is done through locking every index access (e.g. `print(t.a.b)` does four locks). It’s not that multithreading everyone wants and it is off by default behind a compile-time flag. This index-locking approach is trivial and only serves a few specific use cases. Neovim doesn’t seem to use it (because locking every “.” sucks). https://stackoverflow.com/questions/3010974/purpose-of-lua-l...

As for JIT, you have to spin few thousand times in the same loop before it kicks in. It doesn’t just magically speed things up, as it has a very noticeable upfront cost. I think it’s arguable whether this load pattern exists in a usual editor-plugin setting, maybe yes, if you e.g. implement a whole langserver in Lua. But in general, interpreter speed doesn’t matter at all for what is mostly glue code. Neovim doesn’t have its text management core written in Lua to make it matter here.

Also note that Lua is fast because its design choices allow that. Once you ignore these choices, it’s slow again. For example __newindex fires only once. To make an “active object” which always fires newindex, you proxy it via {} and it becomes pythonic. Strings are always interned, so if you work with long strings, you’re constantly recalculating hashes and trashing the heap. So you need a userdata with a buffer with a metatable and everything. Plugin code is naturally “highly embedded”, so JIT stumbles upon embedding API and stops making difference due to “exits”. It’s a very thin line to walk along even if you want that performance.