[0.14.22] get_control_behavior() bad performance

[y.petremann]

In order to create a mod that add programming I used constant combinators as the main entity that hold value and instructions, for it to work I need to read and write on them each ticks, when we start having a lot of them (30 entities) it start lagging, the culprit seems to be the get_control_behavior() method :

1. Start a new sandbox world
2. Place a constant combinator and open it
3. Execute one of these command :
   
   Performance on loading :

   Code: Select all

   /c local entity=game.player.opened script.on_event(defines.events.on_tick, function() if not entity.valid then script.on_event(defines.events.on_tick, nil) else for i=0,64,1 do local map=entity.get_control_behavior().parameters.parameters end end end)

   Performance on saving :

   Code: Select all

   /c local entity=game.player.opened script.on_event(defines.events.on_tick, function() if not entity.valid then script.on_event(defines.events.on_tick, nil) else local chunk={} for i=1,15,1 do chunk[i] = {signal={type="item",name="iron-ore"},count=i,index=i} end for _0=0,64,1 do entity.get_control_behavior().parameters={parameters=chunk} end end end)

4. Enjoy the UPS drop (I get around 20 UPS for each test)

[NiftyManiac]

Yeah, I've seen the same issues, especially with recursive blueprints (https://github.com/justarandomgeek/fact ... t/issues/3). I'd love there to be a way to react to signals on every tick without bogging down performance.

[y.petremann]

Yeah, I've seen the same issues, especially with recursive blueprints (https://github.com/justarandomgeek/fact ... t/issues/3). I'd love there to be a way to react to signals on every tick without bogging down performance.

The only way I've found for now is indexing only what we need and put it in a temporary table to limit the use of get_control_behavior()

[Rseding91]

Yep, that's Lua for you.

There's nothing special about that method other than your calling it a ton, it involves a ton of small strings and tables, and it's Lua.

There's nothing I can do about that - it's working as fast as it can.

[y.petremann]

Yep, that's Lua for you.

There's nothing special about that method other than your calling it a ton, it involves a ton of small strings and tables, and it's Lua.

There's nothing I can do about that - it's working as fast as it can.

The thing is that for the mod that use them, it needs to read them each ticks

For now the workflow each tick is :

• Prepare memory cache (minimal data)
• Run each controllers instructions
  • If memory is needed but not available in cache, load it from corresponding constant combinators (cache is a perfect match of get_control_behavior().parameters.parameters)
  • Process data in memory cache (more than a thousand times)
• Save modified memory to corresponding constant combinators

The fact is that I manipulate the memory cache (getting, setting and modifying) a thousand times more than I use get_control_behavior(), with 30 entities using the 128 cycles of reading and writing to the cache, which correspond to a total of 8192 reading and writing I don't get so much lag, but considering I need communication with the entities each ticks, 60 calls (one to read and one to write for each entity) of get_control_behavior() drop my UPS below 20.

[Adil]

Well, documentation does not state it clearly, but this line:

Note: An control reference becomes invalid once the control behavior is removed or the entity (see LuaEntity) it resides in is destroyed.

Might be interpreted as that you can store the once obtained reference and just check its validity afterwards. I didn't test it yet.

[Rseding91]

Well, documentation does not state it clearly, but this line:

Note: An control reference becomes invalid once the control behavior is removed or the entity (see LuaEntity) it resides in is destroyed.

Might be interpreted as that you can store the once obtained reference and just check its validity afterwards. I didn't test it yet.

Yes, you can do that for virtually all of the objects gotten from Factorio. In fact you should always do that.

[Adil]

It's the absence of `valid` field in documentation on control behavior that caused my hesitations.

[Rseding91]

It's the absence of `valid` field in documentation on control behavior that caused my hesitations.

http://lua-api.factorio.com/latest/LuaC ... vior.brief All of the extended types have the valid property that I can see.

[Adil]

Well, the base class, which I've turned to as a general reference, did not.
Also, LuaCombinatorControlBehavior misses one.

[Rseding91]

Well, the base class, which I've turned to as a general reference, did not.
Also, LuaCombinatorControlBehavior misses one.

The base class and LuaCombinatorControlBehavior can never be gotten in the game. You always get one of the derived types.

[Adil]

You clearly misunderstand how people's mind works.

[Rseding91]

You clearly misunderstand how people's mind works.

It's an API: people have to have some basic level of understanding about how programming works if they want to understand how to use it correctly