Fix #10323: Inefficient Ender Dragon Respawn #12349
Closed
AfonsoMendoncaJacinto wants to merge 1 commit into
Closed
Fix #10323: Inefficient Ender Dragon Respawn #12349AfonsoMendoncaJacinto wants to merge 1 commit into
AfonsoMendoncaJacinto wants to merge 1 commit into
Conversation
007f199 to
d13559e
Compare
This issue likely arose from the method findExitPortal(), which has been optimized. This optimization will ensure better server performance during the respawn sequence and smoother gameplay. Signed-off-by: Afonso Jacinto <afonso.mendonca.jacinto@tecnico.ulisboa.pt>
d13559e to
3d1f58a
Compare
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.
This fixes issue #10323. Currently, the respawn sequence of the Ender Dragon has a noticeable lag spike, likely caused by the method findExitPortal() being poorly optimized, and calling the method find() (which is an expensive method, in terms of server execution time) multiple times, unnecessarily.
Solution: fix index incrementation and direct the search to the most likely spot first, instead of iterating over various blocks, calling find() without first checking whether it makes sense to call it for the instance of the block considered. Also, pre-fetching the relevant chunk does improve following computations.
Profiler links
under stress original version: https://spark.lucko.me/4gqvxg7QBt?hl=9025
under stress with modification: https://spark.lucko.me/tyLvsstn9J?hl=4886
As you can see, the method findExitPortal() is nowhere to be seen, in the second profile report, indicating little impact on server performance. Also, the execution time of the method scanState() went from 5360ms to 60ms.