I don't think it's the elements' fault. I've reduced them to static elements with only a description and no update function and they're just as laggy as before. I think it's due to the simple fact that they're Lua elements, even though I see no reason for them to be laggy if no Lua-side update function is called.

So let me get this straight. The link in the first post (which I've visited, thank you) redirects me to a list of packs of which only one is ready at the moment, and that is not the one you're having problems with, as you've stated in the second post. You have shown us no other piece of code besides that. This means you're asking about code you haven't shown us yet. As my crappy HP printer likes to say, "user interaction required".

I assume elem.DEFAULT_PT_OXYG is the missing constant on line 14.

I don't think there's anything in there that should make this laggy besides, well, this being Lua and all.

Well, the first thing I found is that the else branch in H2SO4's update function is quite the performance hit. I moved the .type ~= H2SO4 check to the front and it's way faster now.

The funny thing is, it's a bit faster if I implement sim.neighbours right there in the function with two inline for loops and a call to partID.