Scripting: add create_entities, set_hidden_tiles, set_double_hidden_tiles

[RedRafe]

Hello,

I would like to ask if adding these APIs would actually benefit game performance by reducing the number of API calls from mods:

LuaSurface::create_entity --> LuaSurface::create_entities
LuaSurface:set_tiles --> LuaSurface::set_hidden_tiles, LuaSurface::set_double_hidden_tiles

[Rseding91]

If you have some code from a mod that appears to be slow, I can try it internally and let you know if such a thing would have any benefit.

[RedRafe]

Sure. Here's a simple code to reproduce what a scenario normally does to create a custom map:

[Rseding91]

I was working on testing this when I realized the code you've given means it will never work for create_entities - because you're checking if each one is placable before placing it - which a "place all of these" would never be able to do.

Removing the "create entity" loop and associated logic and 98% of the time usage is gone.

[RedRafe]

The check for `can_create` can be removed with another code example and in any application where I already know I can (or must force to) place the entity. Main question is if an hypothetical

Code: Select all

surface.create_entities(entities)

would save any non-irrelevant amount of time compared to

Code: Select all

for _, entity in pairs(entity) do
    surface.create_entity(entity)
end

.

And for set_hidden_tiles/set_double_hidden_tiles, since LuaSurface already offers `set_tiles` method, although hidden tiles dont have to adjust tile transitions so maybe having a collection method doesnt change that much

[RedRafe]

Like I could check for can_place before adding the new entity data to the array, and then just pass the array to the API.

[Rseding91]

Like I could check for can_place before adding the new entity data to the array, and then just pass the array to the API.

You could, but the creation of 1 entity can and will effect the can_place of another. So it's not functionally the same if such an API did exist.

Profiling the existing code, roughly 40% of the time is spent creating, iterating and pulling data from the entity tables to check can_place, with another 45% being the create_entity() iteration, pulling data from, and constructing things on the c++ side. The remaining time is spent in set_hidden_tile and set_tiles doing the internal logic.

So I don't think you're going to get any meaningful improvement with a reduced function call overhead when the time spent is not in the function call overhead but the C++ logic to create entities.

[RedRafe]

Alright, thanks for taking the time to check and profile it

[Rseding91]

One possible improvement would be adding a build_check_type to create_entity which would allow you to merge the can_place_entity and create_entity calls. This would roughly half the cost because can_place_entity internally does *almost* the same thing as create_entity, but it then throws it all away to just return "true" or "false".

[RedRafe]

One possible improvement would be adding a build_check_type to create_entity which would allow you to merge the can_place_entity and create_entity calls. This would roughly half the cost because can_place_entity internally does *almost* the same thing as create_entity, but it then throws it all away to just return "true" or "false".

That would be neat. I checked our codebase and "can_place" is roughly always used to ensure mod won't break when trying to place an entity, or not to place it in a weird way, since calling "surface.create_entity("iron-ore")" will (almost) always just easily be true and create it no matter what, while "can_place" would return false if checking for new iron ore on top of pre-existent iron ore, or on top of copper ore, or over water/out-of-map tiles.