… if you copy/paste a combinator. :-)

You should listen to script_raised_built and on_entity_cloned as well, otherwise you will miss that Pollution combinators have been placed! Also, players can use the mod Picker Dollies to move entities. If you'd listen to its custom events (see the mod's info page) as well, you could update the position of your entities.

In case you don't know it yet: Lua API global Variable Viewer (gvv) is a wonderful tool to keep track of your mod's data directly in the game. You can use it to see if combinators have been added to/removed from your table correctly.

Another suggestion: It seems very inefficient to use entity.surface.get_pollution(entity.position)! See here:

Pollution is stored per chunk, so this will return the same value for all positions in one chunk.

I guess it would be better to get the pollution value per chunk once and copy that to the data of each combinator in that chunk. You can't trust that players will never place several combinators in the same chunk, so polling the data just once may be good for UPS, especially as you update all combinators on each tick. :-)

Another suggestion: It seems very inefficient to use entity.surface.get_pollution(entity.position)! See here:

Pollution is stored per chunk, so this will return the same value for all positions in one chunk.

I guess it would be better to get the pollution value per chunk once and copy that to the data of each combinator in that chunk. You can't trust that players will never place several combinators in the same chunk, so polling the data just once may be good for UPS, especially as you update all combinators on each tick. :-)

No, don't do that. Players will not have multiple pollution combinators in the same chunk precisely because it is redundant. And whatever code you use to store values for chunks might be slower than having the occasional double API call. I doubt those API calls are expensive when it's such a simple lookup.

UPS efficient.

So you say. What is efficient about it? Each pollution combinator is updated every tick. That's great if that is what you need, but if I'm going to have these in every chunk then I would prefer to have them update once every 10 seconds probably. And I don't want the game to freeze once every 10 seconds so only some should be updated each tick to spread out the impact. And I would prefer to have a setting for this is possible, but since they don't use input signals it's not going to be very important for me to have them update their output every tick so that might be pointless.

Are pollution values in game even updated every tick anyways? And even if pollution from machines do update add to it every tick I think absorption and spreading of pollution might be slower.

I guess it would be better to get the pollution value per chunk once and copy that to the data of each combinator in that chunk. You can't trust that players will never place several combinators in the same chunk, so polling the data just once may be good for UPS, especially as you update all combinators on each tick. :-)

No, don't do that. Players will not have multiple pollution combinators in the same chunk precisely because it is redundant.

Don't trust anybody: not modders, and certainly not players! :-D

UPS efficient.

So you say. What is efficient about it?

IIRC, the code of this mod gets the chunk pollution for each combinator on each tick. My approach (already implemented in the pollution combinator module of Bio Industries in my WIP version -- I really should get it ready for release) is more efficient: fetch the pollution value for all chunks that have at least one combinator and iff pollution in a chunk has changed, update all combinators in that chunk at once, with the same value. This reduces the number of both read and write operations to the absolute minimum.

Each pollution combinator is updated every tick. That's great if that is what you need, but if I'm going to have these in every chunk then I would prefer to have them update once every 10 seconds probably. And I don't want the game to freeze once every 10 seconds so only some should be updated each tick to spread out the impact. And I would prefer to have a setting for this is possible, but since they don't use input signals it's not going to be very important for me to have them update their output every tick so that might be pointless.

Are pollution values in game even updated every tick anyways? And even if pollution from machines do update add to it every tick I think absorption and spreading of pollution might be slower.

No, don't do that. Players will not have multiple pollution combinators in the same chunk precisely because it is redundant.

Don't trust anybody: not modders, and certainly not players! :-D

You skipped the the real point of my argument. It doesn't matter if you do multiple CHEAP api calls, so time spent avoiding them is time wasted by CPU and the coder. So you are over engineering a solution to a problem that probably doesn't exist even when players do place several pollution combinators in each chunk, where you aren't sure the the "solution" that your code introduces isn't slower than just running the API calls twice. Or did you measure this? If you have 1024 pollution combinators in each chunk then sure your solution might be faster. But no-one does that and it is not worth optimising for. Also, pollution changes all the time, so your "has pollution updated" check is just more overhead that you think speeds it up but I would guess actually slows it down just by storing the old value and doing lookups and comparisons and branching.

And as the potential user of the mod who knows pollution is by chunks and that pollution is updated all the time (as in every time pollution simulation is updated all chunks with pollution will adjust slightly due to spreading and absorption and will not stay exactly the same) I will never benefit from your suggested/implemented "optimizations". My map doesn't have absurd 0 spread and absorption map settings with basically no active polluters at all so pollution values will always update. I won't place 1024 pollution combinators in each chunk. For me, a sane user, your changes are both guaranteed to slow me down (0 checks are faster than some checks) and your code will never be able to reduce updates to combinators or api calls for pollution checking because a sane factory will have minimum api calls naturally. And the necessary data structures you build are pure bloat multiplying the data that is already stored by Factorio. And you are doing all these (admittedly probably very small) slowdowns for the 99.9% of users in the hope that you might reduce the performance hit (that you don't even know if it exists) for the 0.1% of insane users that try to slow down their own factories! Please, I beg you, reconsider and contemplate if you are wasting your time and making your mod unmaintainable with needless complications to your code.

I can trust myself to not do stupid stuff.

What I might have is a pollution combinator in each chunk (realistically probably much less), potentially thousands or tens of thousands of pollution combinators. And pollution takes minutes to really spread and I will only read them once every few seconds and don't even care if the values are a minute old for the factory I have in mind. Not iterating over 10k entities every tick and instead processing 1 per tick can speed it up by 10k times for my usecase. I will probably not have that many pollution combinators and reducing updates to just 1 per tick is probably a bit extreme, but still this is a simple and effective optimization that scales and will be more helpful to extreme pollution combinator build spammers and not affect people with a reasonable amount of pollution combinators at all.