Choumiko wrote:Without having used it, i can maybe give some hints:
You seem to use LuaSurface:find_entities_filtered up to 24 times per chest per tick (12 times for getInputBelts, 12 times for getOutputBelts) in the worst case, i guess you could save a lot of time if you do this in the various events related to placing/mining/rotating/dying entities and save them along with the InterfaceChests in global. It's unlikely that they change every tick, so the more complex work might be worth the effort.
Maybe as a first test change the code so it only looks north for input and only south for output and place a few dozen chests along with belts, etc and observe the timing of your mod.
While it was throttled to not do the tile search every tick I am refactoring that now. In first pass on performance I have 50% improvement
200 chests went from 8-9 to 4ish. I could also slow the chests down from ~compressed redbelt speed to yellow belt speed and reduce the load further.
Instead of filtered search I am now just getting whatever is on the tile and looking through my known list of types my chest can work with and see what it is:
Code: Select all
local entity = game.get_surface(1).find_entities(area)
if entity then
if (entity.type == "transport-belt" or entity.type == "splitter" or (entity.type == "transport-belt-to-ground" and entity.belt_to_ground_type == undergroundType)) and entity.direction == direction then
One weird thing was checking the force of the item seemed to add 1 use-time itself, so for now -- worry about supporting all use cases later.
I'm going to probably pull the surface search up another layer or two and try to get the get_surface calls down as they seem high cost. I could see getting a whole 3x3 area with the chest at the center and then using the result to figure out what the chest should be doing.
I looked over the slipstream mod and it looks like he got through/around this by caching the input/output location on placement. Could be an option. Not sure what his performance ended up at.