Open
Conversation
YoungOnionMC
approved these changes
Mar 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
GT's LevelMixin makes every
getBlockStatecall 6% slower.The mixin exists to allow multiblock validation to happen off-thread. However, the cheap early exits are hidden behind some bitshifts and indirection.
Since
getBlockStateis a very hot path, fast exits should be frontloaded as much as possible, even at the cost of code duplication.This PR moves the most important fast exit to the front.
Implementation Details
I placed the thread check before the clientside check to prioritizing server speed over client speed, though the difference is minimal; both are fast checks.
Outcome
getBlockState runs faster.
How Was This Tested
Game compiles and runs, multiblocks still form.
Additional Information
This is more of a quick fix than a proper solution. Even with this fix, the mixin still causes a CallbackInfoReturnable object to be generated for every
getBlockStatecall, which is not that fast either.Ultimately these mixin injections should not exist at all. The caller (multiblock validator) always already knows that it's the multiblock validator, that it should run async. The caller should not be calling
getBlockState, it should be calling a dedicatedgetBlockStateAsyncmethod. This would not pollute the vanillagetBlockStatemethod with any mixin at all, so there would be zero slowdown.Potential Compatibility Issues
Nothing changed logic-wise.