How does this mod accomplish what it does? Is it scripting? Would adding thousands of these to a modded playthrough (like pY) add up and cause UPS issues?

Just read the code, it checks every (configured) ticks, and it only checks the entity just next to its sensor. I'm not sure it's possible to optimize further. Shouldn't have a huge impact.

It's a pretty huge impact. I placed only 17 around a warehouse in my pY run with a lot of animal parts, and it already added up to 0.4ms or so constant usage, spiking at over 7ms. The spikes are the main problem, i'm not sure what it's doing, maybe checking once every few seconds to see what different items are in the chest or something. But either way, each one was using .02ms, roughly, as I built them. So only 50 of them would be ~1ms constant usage if used on larger warehouse style buildings. And like I said the spikes were huge having only 17 of them.

So unfortunately unless this can be optimized by at least a significant amount more, it won't be usable for a bigger modded run. You might end up using a hundred or more of these around your base and that's going to create lag spikes after only having as few as ~30 of them.

Just read the code, it checks every (configured) ticks, and it only checks the entity just next to its sensor. I'm not sure it's possible to optimize further. Shouldn't have a huge impact.

If it's not possible to optimize, that's a bummer. I'm really kinda lowkey mad at factorio devs for not including ANY way to measure spoilage in the game, even if it was just in the underlying code, but no items in space age made use of it.... It's just really annoying to have these hard restrictions on everything.

About that spikes, it's doing a "update all scanners in a single tick for every nth tick" and "for every update, iterate through all the inventory slots". Performance-wise it is problematic but it should be fine™ in a normal™ playthrough.

I was already aware of this problem when I first coded it but it just has been put into low priority because I can't find an elegant solution for it and it's not necessarily a problem. I'll be addressing this issue on the next release (when I finally get some free time)

That makes sense. Like I am glad the mod exists, but until the mod can properly distribute its UPS overhead over the "scan interval" and "update intervals" such that the user can increase those intervals as desired to get an arbitrary performance, it won't really be usable in a pY run at least. Like I said, only having 17 of them was already bringing the spikes up over 7ms. I'm not sure if that's because the deposit had a lot of items, or if its because it's an 800 slot inventory (probably the latter?), but if that 7ms was distributed over something like 600 ticks? Then it would only be a .01ms overhead! So hopefully someday that can be how it works =D (granted, that would only be if somehow the code could distribute the scan over multiple ticks for a single spoilage scanner, which probably can't work. So at least it could divide the 7ms by 17, and get down to .41ms per scanner, and it distributes those 0.41ms updates evenly over the course of the scan interval, so that if you set it to 600 ticks, you could theoretically have up to 600 scanners and it would just do one scan per tick, and then you'd have an overall overhead of only .41ms still)

I totally understand the free time issue and I make no demands, it's a free mod and you are volunteering your time and energy so thank you for even making the mod. I just am saying it probably won't work for me (or probably most pY players) until this particular issue gets resolved. That being said, I will keep the mod installed because even with that issue, I can still use a few of them around my base, I just have to be extremely limited with their usage. I fear I will do the thing with them that I do with rocket launcher ammo in FPS games.... and just never use them :P

Cross posting the PR I made after this discussion. Krydax will be forever thankful if you merge it :P https://github.com/rekales/spoilage-scanner/pull/3

Released. Very much thanks.

Just downloaded this very cool mod, and both the interval settings seemingly do nothing? No matter if I set it to 36000 the UPS is still the same (not great.)

How are these meant to be configured to work properly?

Edit: Been poking around the source code for a bit and doing some profiling. My conclusion is that a lot of the performance is lost due to the slow for loop at control.lua lines 165 and 171. The 'storage.entity_data' object needs to be reworked to allow iterating over the list faster. Sadly, I am not skilled enough to help with this, though I have tried. :(

wait wut. I don't remember iterating through a table that performance intensive.
It might be config value fetching, it should probably be cached. I'll do it next time when I get some time to try and do some extensive testing. For now it seems like the performance cost isn't that much significant.

I could be wrong of course, but if i comment out the loop the performance issues disappear completely.