The way Item stacks get merged can cause an incredibly long runtime #387
Conversation
…f there is a large amount of times. this can take hours or days if the ItemStack array is large enough. This doesn’t happen during regular gameplay. But it can be caused by crafting continuously with a mod like Itemscroller. Like this the main Consumer while loop gets stuck in the merge. (as it causes 100k+ stacks to be processed) This causes an indefinite (depending on how long you crafted) halt of all database pushes. This can not only render these mods basically unusable, but it also generates a memory leek (as the que is stacked up) and also prevents logging till the merge is done. which, not only prevents proper restarts, but can also lose data when forcefully restarted.
|
What are the steps to replicate this issue, and how does your PR resolve the issue? |
|
How to replicate: using the item scrolled this one:https://github.com/Andrews54757/itemscroller-crafting-fix) mod to craft fast and contiunesly without your inventory getting empty. (I set it to 5ticks Intervall as that is what paper default packet limit while maximumly allow) To do this you need to supply the player with about 6-8 million items an hour. This can be done with command blocks for testing or with sulker unloaders in survival (the way I noticed this) How it resolved the issue: the original code runs in (almost as it doesn't rerun if C2<C1) O(N²) time no mather how many stacks are in the array. This is totally fine for normally array sizes and doesn't take too long. The aforementioned action however can cause the size of the array to be abitrarally large. And with sizes of 100.000+ this can cause the main consumer loop that updates the database to get stuck in it. How it is solved: I check the stack size for zero in the outer loop. ( which mean that the item type has already been merged to a previous stack and therfor make stacking it up again pointless as it simply results in the addition of a lot of 0s) I also moved the check for null values there as it is nessesary to insure it doesn't cause errors. What this means: instead of a constant runtime the runtime varies. With varieing items stays the same. However if there are a lot of the same the entire inner loop gets skipped after the first run. This means the runtime doesn't get out of hand unless someone causes items stacks of different types which is pretty much impossible. Disadvantage if this way: this code runs into an issue if there are stacks of size zero in the input. But that, to my knowledge, should not happen. |
|
added further info in discord in the bug channel. |
If there is a large amount of times. this can take hours or days if the ItemStack array is large enough. This doesn’t happen during regular gameplay. But it can be caused by crafting continuously with a mod like Itemscroller. Like this the main Consumer while loop gets stuck in the merge. (as it causes 100k+ stacks to be processed) This causes an indefinite (depending on how long you crafted) halt of all database pushes. This can not only render these mods basically unusable, but it also generates a memory leek (as the que is stacked up) and also prevents logging till the merge is done. which, not only prevents proper restarts, but can also lose data when forcefully restarted.