Conversation
ChunkMeshWorker.update() sorted the whole proximity list front-to-back and then filtered while walking it, so it ordered thousands of chunks to decide the order of the handful dirty that frame. Filtering first and sorting only those gives the same sequence - ordering and filtering commute here. update() runs once per frame, from RenderableWorldImpl's first rendering stage. Measured on a reproduction of the list and comparator, at the MEGA view distance of 33x7x33 = 7623 chunks: sort-all, list nearly sorted from last frame: ~200us/frame filter-then-sort: ~27us/frame roughly 7x, or ~0.2ms of a 16.7ms frame. The nearly-sorted row is the honest one - a frame re-sorts what it sorted last frame, perturbed only by camera drift, which TimSort handles in about O(n); on a shuffled list the same measurement is ~1.2ms. Either way the cost did not move when the dirty count went from 5 to 50, which is the tell that it was all in touching the list rather than in the queueing. The comparator is not cheap per call: it re-reads the camera through a Provider and, via Chunk.getRenderPosition(), allocates two Vector3f per comparison. So this is really about calling it O(dirty log dirty) times instead of O(n log n). isDirty() is still re-checked immediately before each emit rather than only when the list is built. Emitting can drive mesh generation synchronously, which clears the flag, and add() does not deduplicate - so a chunk present in the proximity list more than once would otherwise be queued again for a mesh the emission before it just produced. ChunkMeshWorkerTest's testChunkIsNotProcessedTwice covers exactly that and caught it. Measured with a throwaway reproduction rather than the real classes: 7623 real ChunkImpls is about a gigabyte, since each carries a dense 16-bit block array. The comparator stand-in used one indirection for the camera where the real one uses two, so the figures understate rather than flatter. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…s per-frame dirty-chunk list
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
soloturn
force-pushed
the
soloturn-chunk-mesh-worker-sort
branch
from
August 27, 2026 19:30
8990896 to
05f2fd4
Compare
soloturn
added a commit
that referenced
this pull request
Aug 27, 2026
From skrcode's PR #5391 review comment (9863 -> 3128 bytes/update measured). Single-threaded, one call per frame - safe to reuse. Cleared in finally. Co-Authored-By: soloturn <soloturn@gmail.com>
Author
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 is a one-commit JAIPilot Cloud follow-up on the exact current head of MovingBlocks/Terasology#5367. It targets that PR branch directly.
Change
Reuse a private per-worker ArrayList for the ready-and-dirty chunk set instead of allocating a new list every rendered frame. A finally block clears the scratch list on both normal and exceptional exits.
Proof
Boundary and disclosure
The session did not complete the entire engine-tests suite, so this claims only the focused tests and affected-module gates. The unchanged comparator remains the dominant allocator. The measurement uses synthetic DummyChunks and is an allocation-count proof, not an end-to-end frame-rate claim.
JAIPilot Cloud generated and validated the patch in skrcode/Terasology#2. I reviewed the exact ancestry, complete one-file diff, call-path ownership evidence, and verification boundary before offering it here.