Optimize exponential histogram builder for in-order construction #135836
Conversation
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
elasticsearchmachine
added
external-contributor
JonasKunz
changed the title
JonasKunz
added
:StorageEngine/Mapping
elasticsearchmachine
added
Team:StorageEngine
and removed
needs:triage
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
kkrik-es
reviewed
Oct 2, 2025
...togram/src/main/java/org/elasticsearch/exponentialhistogram/ExponentialHistogramBuilder.java
Show resolved
Hide resolved
kkrik-es
reviewed
Oct 2, 2025
...togram/src/main/java/org/elasticsearch/exponentialhistogram/ExponentialHistogramBuilder.java
Show resolved
Hide resolved
kkrik-es
reviewed
Oct 2, 2025
.../src/main/java/org/elasticsearch/exponentialhistogram/FixedCapacityExponentialHistogram.java
Show resolved
Hide resolved
kkrik-es
reviewed
Oct 2, 2025
| * @return true, if the last bucket added successfully via {@link #tryAddBucket(long, long, boolean)} was a positive one. | ||
| */ | ||
| boolean wasLastAddedBucketPositive() { | ||
| return positiveBuckets.numBuckets > 0; |
There was a problem hiding this comment.
How so, can't we mix adding positive and negative buckets?
There was a problem hiding this comment.
We use a single array for storage, where we have all buckets for negative values followed by the buckets for positive values. Therefore no, you can't add a negative bucket after a positive one in FixedCapacityExponentialHistogram, this invariant is already enforced by tryAddBucket.
kkrik-es
reviewed
Oct 2, 2025
| // result was already returned on a previous call, return a new instance | ||
| adjustResultCapacity(result.getCapacity(), true); | ||
| } | ||
| assert resultAlreadyReturned == false; |
kkrik-es
reviewed
Oct 2, 2025
...togram/src/main/java/org/elasticsearch/exponentialhistogram/ExponentialHistogramBuilder.java
Outdated
Show resolved
Hide resolved
kkrik-es
approved these changes
Oct 2, 2025
felixbarny
approved these changes
Oct 6, 2025
kkrik-es
approved these changes
Oct 7, 2025
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.
Prior to this PR, the exponential histogram builder was only intended for usage in tests.
It was very allocaty and inefficient under high load, due to internally using
TreeMaps for storing the histogram buckets prior to building.This PR makes the builder efficient by introducing a happy path: If the buckets are provided in order, we directly construct the result
FixedCapacityExponentialHistogram, avoiding unnecessary copies, allocations and sorting.In addition, it is possible to provide the bucket count in advance if available, to avoid resizing.
It is still possible to provide the buckets out of order. We detect this case and then fallback to using the
TreeMaps for bucket storage.This is required, because for #135625 we'll have to introduce wire (de)serialization code for exponential histograms, which internally will use the builder and therefore needs to be efficient. In addition it looks like for ES|QL histogram copying is required, which is also made more efficient with this PR.