Reduce allocations in AsyncTaskIndexService#142290
Merged
DaveCTurner merged 5 commits intoelastic:mainfrom Feb 13, 2026
Merged
Conversation
Today we create our buffer with a zero `expectedSize` which prefers to repeatedly allocate with `new byte[]` instead of using recycled pages until the buffer contents get big enough. With this commit we always allocate a (recycled) whole page instead, avoiding all those allocations.
DaveCTurner
added
>non-issue
:StorageEngine/ES|QL
Collaborator
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
alex-spies
reviewed
Feb 11, 2026
Contributor
alex-spies
left a comment
alex-spies
left a comment
There was a problem hiding this comment.
This change looks reasonable to me, but I'd defer to someone who's got more experience with the async indices and our page recycling to approve.
nik9000
approved these changes
Feb 12, 2026
Member
nik9000
left a comment
nik9000
left a comment
There was a problem hiding this comment.
I've got the experience with the recycler. This will keep us from allocating a byte array most of the time. Looks good to me.
DaveCTurner
added a commit
to DaveCTurner/elasticsearch
that referenced
this pull request
Feb 13, 2026
This caught me out in elastic#140365: we actually don't use the slow-growth behaviour by default with a `ReleasableBytesStreamOutput`, you have to ask for it. But we do ask for it sometimes, so this commit fixes the docs and one of the places where we do. Relates elastic#142290, which fixes another case of this.
Member
Author
|
I just noticed that you get the same behaviour, but needing less explanation, if you just drop the |
sidosera
pushed a commit
to sidosera/elasticsearch
that referenced
this pull request
Feb 13, 2026
Today we create our buffer with a zero `expectedSize` which prefers to repeatedly allocate with `new byte[]` instead of using recycled pages until the buffer contents get big enough. With this commit we always allocate a (recycled) whole page instead, avoiding all those allocations.
DaveCTurner
deleted the
2026/02/11/AsyncTaskIndexService-INITIAL_BUFFER
branch
DaveCTurner
added a commit
that referenced
this pull request
Feb 19, 2026
…42451) This caught me out in #140365: we actually don't use the slow-growth behaviour by default with a `ReleasableBytesStreamOutput`, you have to ask for it. But we do ask for it sometimes, so this commit fixes the docs and one of the places where we do. Relates #142290, which fixes another case of this.
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.
Today we create our buffer with a zero
expectedSizewhich prefers torepeatedly allocate with
new byte[]instead of using recycled pagesuntil the buffer contents get big enough.
With this commit we always allocate a (recycled) whole page instead,
avoiding all those allocations.