Chests/inventories could probably be optimized

[Architector_4]

I am having a playthrough with a multitude of mods, and one of them is Merging Chests mod: https://mods.factorio.com/mod/WideChests

That mod basically allows making really big chests, but has a chest inventory size cap of 1000 slots. Nonetheless, I've noticed that my UPS went down significantly over time (constant 8 UPS is sure fun ).

That prompted me to test if that is related. I:
1. Started Factorio (1.1.32, from Steam, Linux) with only that mod enabled;
2. Changed the cap in mod settings from 1000 to 65535 (maximum possible);
3. Started map editor on freeplay, placed two 40x40 chests from the mod next to each others, with powered stack inserters going both ways inbetween.
4. Set time speed to 64x and started it, got about 3800 UPS.

After that I loaded a stack of steel chests into one of them. UPS instantly dropped to about 600 - a 7-fold performance drop!!

I mean, I understand that moving stuff between two chests with 65535 slots isn't a realistic benchmark, but I nonetheless feel like it could be very well improved. Both chests only ever had their first slot disturbed, since there's only 1 slot worth of items running around total - how come the other 65534 slots without anything slow it down this much? I'd imagine that even in vanilla, in some cases, 47 empty slots of a steel chest have a lesser yet still similar impact lol


I understand if it's unreasonable to optimize it considering only vanilla, or considering that it may probably take significant effort better spent doing other stuff, but I nonetheless wish this would be optimized.

To think of it - isn't a lane of a conveyor belt and a line of chest item slots kind of functionally similar? Maybe chests could be optimized in the exactly the same vein as conveyor tracks? Or maybe just internally scale the inventory as items go in/out until it hits the limit that it's supposed to have, so no issues would arise from a ton of empty slots?

[ssilk]

Are you sure it was by the game engine and not by the mod? Have you been looking at the time that mod needs? (Debug mode)

[Architector_4]

Are you sure it was by the game engine and not by the mod? Have you been looking at the time that mod needs? (Debug mode)

By debug mode, do you mean the "Debug settings" that open on F4? If so, I am not sure how can I check the time that the mod needs - in particular, not sure which debug flags to use. The show-time-usage flag shows huge numbers with "> Wait For Update" line when in the test scenario every time inserters hit the chests, as well as with "Entity update" line. The show-entity-time-usage flag shows "8Inserter" line with huge numbers as well.

If it's the inserters eating up this much time, then I doubt it has to do much with the mod (especially considering that the chests do have the "Merging Chests" tag in the description/tooltip suggesting it's related to a mod, but the inserters don't). Probably an ignorant statement, but the entire singular thing this mod does is add chests that are big - I don't see how there would be anything from the mod lowering performance, besides setting up the engine with a precedent (huge chests) that amplifies performance loss of the engine's machinations.


I am attaching the scenario I made in the editor that causes the huge UPS dips for me, in case you want to check it out - all the inserters are synchronized in their movement, so they all hit the chest simultaneously and cause huge performance spikes together (also try setting time to 64x, in case your PC is so good as to survive the spikes and not fall below 60UPS). The dependencies is that mod linked in the original post, at version 3.3.0, with mod setting of inventory size limit set to 65535, and Factorio base of version as per the post.

To prove my point, if you do see at least some performance loss, try changing the inventory size limit mod setting to something benign like "10" and then starting the test yet again. When you do that, suddenly no performance loss happens, even though exactly the same thing is happening! Even if the mod does anything that impacts performance, I'd imagine it would still do the same thing regardless of the amount of slots in the chests - but the performance loss most obviously happens only with when the chests have huge inventories, and hence I suspect it to be a problem of the engine.

If anything, maybe I should try making a little "mod" that just adds a chest identical to steel chest but with 65535 slots, and then do the test that way. Probably would be a more fair test in any case lol

[ptx0]

next patch changelog:

* fixed chest performance by limiting slots to 48

[ptx0]

the reason is because the engine iterates every slot from the end to the beginning until it finds a stack that contains the needed item.

it is indeed, quite a stupid search.

i could ask for a show of hands who has written code this badly, but instead i'll go to each of you one by one and ask the same exact question.

in other words, instead of using optimised / normalised data structures for the logic, they're storing data in a way that the user will want to look at it. this is absolutely irritating. should have used literally any other style of data lookup. hash tables were taught on day one.

[darkfrei]

https://mods.factorio.com/mod/SmallChests
viewtopic.php?f=23&t=20666

[ssilk]

In any case it looks to me like something for
viewtopic.php?f=5&t=17501 Performance optimization - post your saves

By debug mode, do you mean the "Debug settings" that open on F4? If so, I am not sure how can I check the time that the mod needs - in particular, not sure which debug flags to use.ay. Probably would be a more fair test in any case lol

I mean show-lua-object-statistics.

[ptx0]

In any case it looks to me like something for
viewtopic.php?f=5&t=17501 Performance optimization - post your saves

By debug mode, do you mean the "Debug settings" that open on F4? If so, I am not sure how can I check the time that the mod needs - in particular, not sure which debug flags to use.ay. Probably would be a more fair test in any case lol

I mean show-lua-object-statistics.

you could look at its control.lua to see that it only runs when the player uses the hand tool.

it doesn't churn objects or do any other runtime scripting. the burden is entirely from the game engine's implementation of slot sweep.

[Architector_4]

Thanks for your input, everyone.

I mean show-lua-object-statistics.

As the other post noted, there is no scripts from the mod running except for the additional tool when specifically used by the user, so I guess we can rule that out.

In any case it looks to me like something for
viewtopic.php?f=5&t=17501 Performance optimization - post your saves

I guess I'll go ahead and post it there.

[eradicator]

It's not like this knowledge is new or anything. https://mulark.github.io/tests/test-000 ... 00004.html
On "insert into" interters iterate the whole inventory to check if there are any half-full stacks, and on "take out of" they iterate to find the last stack available. As storing large heaps of stuff is usualy not really useful in factorio chests should imho be optimized to make small chests as fast as possible. So the question is if large chests can be optimized without making small ones slower.

[Nosferatu]

It's not like this knowledge is new or anything. https://mulark.github.io/tests/test-000 ... 00004.html

Thanks for posting that. Learned something today:
Using smaller chests saves performance.
But it's not necessary to use wooden chests. Limiting them is enough

[Architector_4]

It's not like this knowledge is new or anything. https://mulark.github.io/tests/test-000 ... 00004.html
On "insert into" interters iterate the whole inventory to check if there are any half-full stacks, and on "take out of" they iterate to find the last stack available. As storing large heaps of stuff is usualy not really useful in factorio chests should imho be optimized to make small chests as fast as possible. So the question is if large chests can be optimized without making small ones slower.

That's fair. However, I'd imagine the "overhead" of using something like a binary search or a hash table would be negligible and wouldn't impact small chests while massively optimizing the bigger ones (I'd imagine a steel or even an iron chest would benefit from this).

It may be worth it to just use one code path if a chest is small but another if it's big?

At the very least, I feel like just storing the number of last non-empty cell with each chest and then only iterating up to that number (plus one if needed) would provide no overhead and would just improve chests all around lol

[disentius]

@nosferatu: No, it isn't. You can limit chests while there are items in the stacks you are limiting, so the check has to be on all stacks.

2021-04-19 12_18_44-Window.png (28.98 KiB) Viewed 6351 times

@Architector_4: If it was a simple fix they would have done it already; the devs are very optimisation minded.
Read some FFF's to see how much.
It would be nice if they would explain why they made this design choice, and why it is hard to optimize big chests/warehouses more.

[ickputzdirwech]

This thread from 2018 also talks about optimisations of chests: 62779. Sounds to me like it is related.

[disentius]

And some explanation about the current design choice here: viewtopic.php?p=220715#p220715 and viewtopic.php?p=351657#p351657

[Nosferatu]

@disentius
The linked test came to that conclusion but it only mentions inserting into a chest. Has someone tested the other direction?

[Architector_4]

If it was a simple fix they would have done it already; the devs are very optimisation minded.

I agree that they do very great optimizations, but that does not mean that Factorio developers are literally omni-aware gods that can and will think of every single way to optimize every single thing at all times. They are human, just like you are and I am. With that in mind, a thought process of "since someone is good at doing something, that must mean they do it well every single time" is toxic and absurd.

I am only pointing out something that doesn't seem to be well optimized, and trying to make reasonable suggestions on how it could be optimized and why would that might have a benefit (even if that benefit is significant only on a modded playthrough), based on my guesses on how the game works. Since the game engine is proprietary and nobody except the developers can view or improve the source code, that's the best feasible way I have of trying to improve this particular single thing that bit me in the rear hard in my latest playthrough.

[eradicator]

I'd imagine the "overhead" of using something like a binary search or a hash table would be negligible
[...]
It may be worth it to just use one code path if a chest is small but another if it's big?
[...]
At the very least, I feel like just storing the number of last non-empty cell with each chest

Sounds to me like you're only considering CPU overhead and forgetting about other things like RAM, savetime, code maintainability etc. There's been numerous occasions where the devs rejected CPU optimizations because they would cost too much RAM or cache misses. (This is just a fact, I'm not saying they're always right.)

From a purely logical standpoint however: Even "just storing non-empty cell index" means that each inserter on every swing has to try to update that index. I don't know how much that costs, but it's not "free". And in the end such optimizations only affects "large chests that are mostly empty". It doesn't improve the much more common case of full chests. (And I wouldn't be suprised if at least part of the reason is that the devs do not want to encourage usage of ridiculously large chests for gameplay reasons too.)

[ptx0]

If it was a simple fix they would have done it already; the devs are very optimisation minded.

I agree that they do very great optimizations, but that does not mean that Factorio developers are literally omni-aware gods that can and will think of every single way to optimize every single thing at all times. They are human, just like you are and I am. With that in mind, a thought process of "since someone is good at doing something, that must mean they do it well every single time" is toxic and absurd.

I am only pointing out something that doesn't seem to be well optimized, and trying to make reasonable suggestions on how it could be optimized and why would that might have a benefit (even if that benefit is significant only on a modded playthrough), based on my guesses on how the game works. Since the game engine is proprietary and nobody except the developers can view or improve the source code, that's the best feasible way I have of trying to improve this particular single thing that bit me in the rear hard in my latest playthrough.

the bottom line is an unwillingness to compromise on 'aspects of the simulation' like having lockable slots that can contain partial stacks. do you know how Satisfactory optimised their inventories? by not having that nonsense occur. the slots are always sorted, and you can't halve a stack.

we do pair programming at my workplace and constantly mob with other team members who point out things my partner and I missed because we're so deep in the weeds on a problem.

this is the kind of reason why open source is so amazing. anyone can come along and submit a pull request to prove the devs wrong instead of having to "simply take our word for it".

i almost had source access, kovarex asked for my github username and then didn't respond. someone else on the team probably said there's no reason to grant access.

[ptx0]

Sounds to me like you're only considering CPU overhead and forgetting about other things like RAM, savetime, code maintainability etc. There's been numerous occasions where the devs rejected CPU optimizations because they would cost too much RAM or cache misses. (This is just a fact, I'm not saying they're always right.)

From a purely logical standpoint however: Even "just storing non-empty cell index" means that each inserter on every swing has to try to update that index. I don't know how much that costs, but it's not "free". And in the end such optimizations only affects "large chests that are mostly empty". It doesn't improve the much more common case of full chests. (And I wouldn't be suprised if at least part of the reason is that the devs do not want to encourage usage of ridiculously large chests for gameplay reasons too.)

sorry, what do you think CPU use reduction does? somehow increase memory use while reducing CPU calls? not how it works. by reducing memory use, you can reduce CPU consumption.

in any case, spending less time spinning in CPU is a gain - no matter if it's because we've reduced interactions or simplified the routines so they do fewer things.

updating an index would be an order of magnitude faster than iterating over every single slot on every single swing.

but i've offered up an incredibly profound solution by replacing malloc with mimalloc and rseding91 says "only" 6% gain through reduced TLB misses. i guess that's not enough for him. so 6% performance loss couldn't be too hard to convince him to accept?