Chests/inventories could probably be optimized

Post your ideas and suggestions how to improve the game.

Moderator: ickputzdirwech

User avatar
Architector_4
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sat Apr 17, 2021 2:04 pm
Contact:

Chests/inventories could probably be optimized

Post by 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 :D).

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?

User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12412
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by 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)
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
Architector_4
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sat Apr 17, 2021 2:04 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by Architector_4 »

ssilk wrote:
Sat Apr 17, 2021 11:16 pm
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
Attachments
huge-chest-lag.zip
(720.43 KiB) Downloaded 128 times

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by ptx0 »

next patch changelog:

* fixed chest performance by limiting slots to 48 :lol:
My Mods - Fish Per Minute base size metric - Use your crashed spaceship as a belt balancer?
• • •
Base: Bob's @ 1 Million SPM
• • •
Linear search and overflows are indicative of sloppy coding practices.

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by 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. :lol:
My Mods - Fish Per Minute base size metric - Use your crashed spaceship as a belt balancer?
• • •
Base: Bob's @ 1 Million SPM
• • •
Linear search and overflows are indicative of sloppy coding practices.


User avatar
ssilk
Global Moderator
Global Moderator
Posts: 12412
Joined: Tue Apr 16, 2013 10:35 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by ssilk »

In any case it looks to me like something for
viewtopic.php?f=5&t=17501 Performance optimization - post your saves
Architector_4 wrote:
Sun Apr 18, 2021 12:06 am

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.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by ptx0 »

ssilk wrote:
Sun Apr 18, 2021 5:13 am
In any case it looks to me like something for
viewtopic.php?f=5&t=17501 Performance optimization - post your saves
Architector_4 wrote:
Sun Apr 18, 2021 12:06 am

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.
My Mods - Fish Per Minute base size metric - Use your crashed spaceship as a belt balancer?
• • •
Base: Bob's @ 1 Million SPM
• • •
Linear search and overflows are indicative of sloppy coding practices.

User avatar
Architector_4
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sat Apr 17, 2021 2:04 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by Architector_4 »

Thanks for your input, everyone.
ssilk wrote:
Sun Apr 18, 2021 5:13 am
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.
ssilk wrote:
Sun Apr 18, 2021 5:13 am
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.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5201
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Chests/inventories could probably be optimized

Post by 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.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
Nosferatu
Fast Inserter
Fast Inserter
Posts: 144
Joined: Fri Jan 20, 2017 4:48 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by Nosferatu »

eradicator wrote:
Mon Apr 19, 2021 6:01 am
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

User avatar
Architector_4
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sat Apr 17, 2021 2:04 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by Architector_4 »

eradicator wrote:
Mon Apr 19, 2021 6:01 am
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

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 590
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by 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
2021-04-19 12_18_44-Window.png (28.98 KiB) Viewed 1232 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.

User avatar
ickputzdirwech
Filter Inserter
Filter Inserter
Posts: 649
Joined: Sun May 07, 2017 10:16 am
Contact:

Re: Chests/inventories could probably be optimized

Post by ickputzdirwech »

This thread from 2018 also talks about optimisations of chests: 62779. Sounds to me like it is related.
Mods: Shortcuts for 1.1, ick's Sea Block, ick's vanilla tweaks
Tools: Atom language pack
Text quickly seems cold and unfriendly. Be careful how you write and interpret what others have written.
- A reminder for me and all who read what I write

User avatar
disentius
Filter Inserter
Filter Inserter
Posts: 590
Joined: Fri May 12, 2017 3:17 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by disentius »

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

User avatar
Nosferatu
Fast Inserter
Fast Inserter
Posts: 144
Joined: Fri Jan 20, 2017 4:48 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by Nosferatu »

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

User avatar
Architector_4
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sat Apr 17, 2021 2:04 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by Architector_4 »

disentius wrote:
Mon Apr 19, 2021 10:25 am
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.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5201
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Chests/inventories could probably be optimized

Post by eradicator »

Architector_4 wrote:
Mon Apr 19, 2021 10:06 am
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.)
Last edited by eradicator on Mon Apr 19, 2021 7:35 pm, edited 1 time in total.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by ptx0 »

Architector_4 wrote:
Mon Apr 19, 2021 5:41 pm
disentius wrote:
Mon Apr 19, 2021 10:25 am
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". 8-)

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.
Last edited by ptx0 on Mon Apr 19, 2021 7:41 pm, edited 1 time in total.
My Mods - Fish Per Minute base size metric - Use your crashed spaceship as a belt balancer?
• • •
Base: Bob's @ 1 Million SPM
• • •
Linear search and overflows are indicative of sloppy coding practices.

User avatar
ptx0
Smart Inserter
Smart Inserter
Posts: 1120
Joined: Wed Jan 01, 2020 7:16 pm
Contact:

Re: Chests/inventories could probably be optimized

Post by ptx0 »

eradicator wrote:
Mon Apr 19, 2021 7:32 pm
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? :?
My Mods - Fish Per Minute base size metric - Use your crashed spaceship as a belt balancer?
• • •
Base: Bob's @ 1 Million SPM
• • •
Linear search and overflows are indicative of sloppy coding practices.

Post Reply

Return to “Ideas and Suggestions”