Page 1 of 1

[0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 2:27 am
by 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)

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 2:56 am
by 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.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 3:41 am
by y.petremann
NiftyManiac wrote: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()

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 8:04 am
by 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.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 9:51 am
by y.petremann
Rseding91 wrote: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.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 10:22 am
by 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.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 10:36 am
by Rseding91
Adil wrote: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.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 11:57 am
by Adil
It's the absence of `valid` field in documentation on control behavior that caused my hesitations.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Fri Feb 24, 2017 1:49 pm
by Rseding91
Adil wrote: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.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Sat Feb 25, 2017 8:19 pm
by Adil
Well, the base class, which I've turned to as a general reference, did not.
Also, LuaCombinatorControlBehavior misses one.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Sat Feb 25, 2017 10:31 pm
by Rseding91
Adil wrote: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.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Sat Feb 25, 2017 11:15 pm
by Adil
You clearly misunderstand how people's mind works.

Re: [0.14.22] get_control_behavior() bad performance

Posted: Sat Feb 25, 2017 11:31 pm
by Rseding91
Adil wrote: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 :)