diff options
| author | Uristqwerty <Uristqwerty@gmail.com> | 2020-11-26 04:29:20 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-11-26 10:29:20 +0100 |
| commit | a65bc5d9189095398d85b36cb0e2890ef5f106ce (patch) | |
| tree | 9ab16bc995bcff41bb0f3f509119f8b03deec8d0 /src/main/java/gregtech/api/events/BlockScanningEvent.java | |
| parent | ce81af0017487e0f914befc28a8151b6ff70d7a7 (diff) | |
| download | GT5-Unofficial-a65bc5d9189095398d85b36cb0e2890ef5f106ce.tar.gz GT5-Unofficial-a65bc5d9189095398d85b36cb0e2890ef5f106ce.tar.bz2 GT5-Unofficial-a65bc5d9189095398d85b36cb0e2890ef5f106ce.zip | |
isRecipeInputEqual optimization (#351)
* Optimize GT_Recipe.isRecipeInputEqual
Used HEAVILY to catch duplicate recipes during game startup. Worst-case, it
would result in 5 GT_OreDictUnificator.get calls for each pair of inputs.
Instead, this is closer to 1 + 1/N, and as an added bonus, the modified
unification it now uses doesn't copy its output only for it to be discarded
immediately after comparison.
Apart from inproved startup times, this might make a small difference when
machines switch recipes.
I am making an assumption that
GT_OreDictUnificator.get(true, GT_OreDictUnificator.get(false, stack))
is equivalent to a just GT_OreDictUnificator.get(false, stack), and the
original code only double-unificated because it was easier to code. If this
turns out to be false, there's still some performance gain from factoring
out the tStack unification, but some of the optimization here would be lost.
* Changed method visibility according to PR feedback
Diffstat (limited to 'src/main/java/gregtech/api/events/BlockScanningEvent.java')
0 files changed, 0 insertions, 0 deletions