Skip recipe checks if input contains only programmed circuits. #3305
Conversation
AbdielKavash
added
the
enhancement
|
i like the idea, but idk how you managed to pull out the data for your table. For instance, i get from this link https://spark.lucko.me/P2DHmDpd2i 988 ms over 120 000 ms (2 min of profile time) which is 0.76% of the CPU load. This look quite promising, however, idk much about the backend processing much to approve or requests changes. |
This is what I'm looking at: |
|
How have you tested this? I think we'll have to scream test it on the nightlies regardless, but a quick sanity check on the common machines would be good. |
I have tested that the machine can still in fact run recipes, both with and without circuits in the input bus. I have done this for both multiblocks (EBF, bender, some other representatives of edge cases) and singleblock versions of the same. I have also explicitly tested the Matter Fabricator multi. If there is anything else that you'd like me to check, let me know. |
Background
Many machines use programmed circuits as a non-consumed input in their recipes. To automate such a process, the player typically leaves a circuit in the machine's input bus permanently, and inserts other inputs as needed. Moreover, certain "universal" setups rely on keeping several circuits in the input bus, and use recipe check order to pick the correct recipe when input items are inserted. As an example, one can run an electric blast furnace with circuits [1] and [11] in the bottom-right slots of an input bus; and when the EBF receives an input dust, it will use a circuit [11] recipe if available, otherwise a circuit [1] recipe, and finally a recipe without any circuits. This allows for automating many different recipes using only one machine.
The downside to this setup is that circuits in an input bus are still treated as items for the purpose of recipe checks (and this applies to phantom circuits set in the input bus's UI as well). This means that a machine with several circuits in its input bus iterates over its recipe map over and over with each recipe check, even though from the player's point of view the machine is effectively idle. When scaled up, and especially with machines with long recipe lists (EBF, LCR, ...), this starts having noticeable impact on tick times (see Evaluation section below). In fact I have noticed this in my survival world with Volcanuses and MCRs.
This PR modifies recipe checks in such a way that programmed circuits are no longer counted towards the number of items in the input bus. This means that if the input bus contains only circuits, it is treated as being empty, and thus recipe checks are completely skipped.
I note that this only specifically affects GT programmed circuits, and not the GT++ bio or breakthrough circuits, or other similar items (shapes, molds, lenses etc.) A more generic solution could be developed, but I wanted to keep the impact of this change minimal for now.
Evaluation
I have tested the performance impact in a new test world, with 256 Electric Blast Furnaces, with input buses configured as in the table below. In all cases except for the last circuits are the only items in the EBF's input, and therefore it is impossible for it to run any recipes. Comparison is made between 2.5.7-beta-2, and the same pack with only this change added. I note that the table only shows the average time. Since recipe checks are not run every tick, the actual impact on maximal tick time (which contributes to TPS spikes) is even larger than the table shows. Spark profiler results are included.
The number in the table is specifically time spent in
MTEMultiBlockBase.checkProcessing().Caveats
Since every input item is now tested for being a circuit, this change could have a negligible performance effect in case there are many non-circuit items in the input bus. However, this is not the case in a typical setup; and in my testing I was unable to measure any difference; see last row of table above.
More importantly, this change modifies the semantics of
RecipeMapBuilder.minInputs(). Previously the minimum number of item inputs included any programmed circuits which were a part of the recipe. After this change, since circuits are ignored when counting input items, the minimum number of inputs must be set to the number of "real" (non-circuit) items in any recipe.For example, previously a Bending Machine required a minimum of 2 inputs: a metal ingot, and a programmed circuit. With this change, the minimum number of inputs is set to 1 (the ingot), since the circuit is no longer counted.
I did my best diligence to update the
minInputs()calls everywhere this makes a difference, and I tested several machines in the beta version to ensure that all recipes still run correctly. However I would appreciate someone double-checking that I haven't missed anything.Finally, if the only thing in a machine's inputs is a circuit (no other items and no fluids), recipe checks are skipped completely. This means that if a recipe takes no inputs other than a circuit, it will not be able to be processed correctly. This is currently the case for only one machine: the GT++ Matter Fabricator multiblock. The Rock Breaker and Zhuhai Fishing Port have similar recipes; however they implement their own processing logic and so they are not affected.
I have added a skip to this last check in form of
RecipeMapBuilder.allowCircuitOnly()(seeGTPPRecipeMaps.java:38) so that these recipes work correctly; this is used for the Matter Fabricator, but it can also be used for any future machines which might need such recipes.