Repository navigation
Avoid allocations on MarkerEntry cache hits - #4469
Merged
vogella merged 1 commit intoOct 11, 2026
Merged
Conversation
There was a problem hiding this comment.
🟢 Approval recommended
The focused optimization preserves existing behavior and introduces no unresolved correctness issues.
0 open findings
What changed in this PR
Optimizes marker sorting by eliminating lambda allocations on cache hits while preserving existing computations.
Changes:
- Adds direct cache lookups before deferred computation.
- Extracts marker attribute, location, and path computations into private methods.
- Avoids unnecessary collation-key computation lambdas on hits.
| File | Description |
|---|---|
MarkerEntry.java |
Introduces allocation-free cache-hit paths for marker values and collation keys. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
The markers views read cached marker attributes, the location, the path and description collation keys inside every sort comparison. Each read allocated a capturing lambda for the computation, and computeIfAbsent allocated a second one, even when the value was already cached. Look the value up with a plain get first and pass non-capturing compute functions, so a cache hit allocates nothing. Assisted-by: multiple AI agents and layers of automated tooling 🤖
vogella
force-pushed
the
lv/marker-entry-cache-lookup
branch
from
October 11, 2026 10:44
00dbea1 to
6e55229
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.
The Problems, Tasks and Markers views read cached marker attributes, the location, the path and description collation keys inside every sort comparison. Each of these reads allocated a capturing lambda for the computation and computeIfAbsent allocated a second one, even when the value was already cached, so sorting a large marker list produced garbage proportional to the number of comparisons. This change looks the value up with a plain get first and passes non-capturing compute functions, so a cache hit allocates nothing. The computations themselves are unchanged, only moved into private methods.