[Performance] Use ArrayDeque for remaining LinkedList queues#516
Open
Jawnnypoo wants to merge 2 commits into
Open
[Performance] Use ArrayDeque for remaining LinkedList queues#516Jawnnypoo wants to merge 2 commits into
Jawnnypoo wants to merge 2 commits into
Conversation
Replaces LinkedList with ArrayDeque in the three remaining queue fields: globalEffectQueue (FormulaRuntime), transitionQueue (FormulaManagerImpl), and BatchImpl.updates. ArrayDeque is backed by a circular array with better cache locality and no per-element node allocation, which matches the usage pattern here (add-to-tail / remove-from-head with no random access or iterator mutation). Continues the precedent set in #497 ([Performance] Use ArrayDeque for startEffect). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
JaCoCo Code Coverage 93.86% ✅
Generated by 🚫 Danger |
📊 Benchmark Comparison ReportSummary
🎉 Performance Improvements
No significant changes (2 benchmarks)
Regressions: ±10% with non-overlapping confidence intervals. Improvements: ±10% change only. Generated by 🚫 Danger |
Laimiux
reviewed
Jun 16, 2026
|
|
||
| private val isScheduled = AtomicBoolean(false) | ||
| private val updates = LinkedList<() -> Unit>() | ||
| private val updates = ArrayDeque<() -> Unit>() |
Collaborator
There was a problem hiding this comment.
Some things to consider with ArrayDeque
- What is the initial memory allocation? Is that right for our use case?
- I'm not sure if ArrayDeque sizes down. How likely is it that it spikes in items for a brief moment and then stays there long-term.
Member
Author
There was a problem hiding this comment.
Good callout. It sounds as though the initial memory size would be quite small, less than 100 bytes. As for growing infinitely, that is in fact a problem that this would introduce, though I think even in the thousands, it would be maybe a few kilobytes of memory usage.
We can size down manually. Let me look into that.
ArrayDeque never shrinks its backing array on its own — once a burst grows the deque, that capacity stays pinned for the life of the holder. For the two long-lived queues (FormulaRuntime.globalEffectQueue and FormulaManagerImpl.transitionQueue), this means a transient cascading transition could permanently inflate per-runtime / per-manager memory. Fix: - Give each deque a small initial capacity sized for the common case (8 effects, 4 deferred transitions, 4 batch updates) instead of relying on the stdlib's lazy default of 10. - For the two long-lived queues, track the high-water mark and replace the deque with a fresh one at a natural drain-to-empty point if the burst exceeded a shrink threshold. BatchImpl.updates doesn't need this — the instance is single-shot and GC'd after execute(). Thread safety is unchanged: both queues are accessed only under the existing SynchronizedUpdateQueue serialization, so field reassignment is safe without @volatile (happens-before is established via the threadRunning atomic). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
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
4 participants
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.
Summary
LinkedListwithArrayDequein three remaining queue fields:FormulaRuntime.globalEffectQueue,FormulaManagerImpl.transitionQueue, andBatchImpl.updates.Why
All three fields are used as FIFO queues — add-to-tail, remove-from-head, no random access, no mid-iteration mutation.
ArrayDequeis strictly better for this workload:LinkedList's per-element heap-allocatedNodes.Compatibility notes
private, so no external API change.pollFirst()calls were switched toremoveFirst()— every call site is already guarded byisNotEmpty(), so the throw-vs-return-null difference is not observable.BatchImpl.updatesis still passed asList<() -> Unit>toBatchManager.Executor.executeBatch;ArrayDequeimplementsMutableList, so this is unchanged.LinkedListallowed mid-iteration mutation viaListIterator;ArrayDequethrowsConcurrentModificationException. None of the affected code paths use iterators — they all drain viaremoveFirst()in awhile (isNotEmpty())loop, which works the same on both.Test plan
./gradlew :formula:testpasses locally.🤖 Generated with Claude Code