Optimize slicing ReleasableBytesReference to avoid needless retention of unused pages #126284
Conversation
… of unused pages We can make slicing things like search hits where we cut many small buffers out of a large composite reference a lot more efficient in some cases by making the slice of a releasable reference itself releasable. This fixes the current situation where we could have composite buffer of many MB that is made up of e.g. 16k chunks but that we would retain in full if we were to slice even a single byte out of it in any position.
original-brownbear
added
>non-issue
:Distributed Coordination/Network
elasticsearchmachine
added
v9.1.0
Team:Distributed Coordination
|
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
| if (from == 0 && length() == length) { | ||
| return retain(); | ||
| } | ||
| final BytesReference slice = delegate.slice(from, length); |
There was a problem hiding this comment.
Funny enough I found this looking into a different optimization that wouldn't build composite bytes references out of releasable ones by unwrapping. While that has its runtime advantages, this change seems much more helpful by saving memory and optimisations like #124947 (if taken a little further that is) could leverage this for even bigger gains.
As it stands, this change actually is quite helpful already when working with SearchHit instances sliced out of large buffers at the very least (there might be other cases where it's helpful as well). Also, it avoids a pointless round of ref-counting in the decoder.
There was a problem hiding this comment.
This could also be taken further by making the logic aware of situations where the slice itself is made up of a subset of the releasable references that the parent instance consists of and only retaining those. Obviously then considerably increasing the complexity of the implementation for a likely limited gain in corner cases.
|
Thanks David! |
3 participants
We can make slicing things like search hits where we cut many small buffers out of a large composite reference a lot more efficient in some cases by making the slice of a releasable reference itself releasable. This fixes the current situation where we could have composite buffer of many MB that is made up of e.g. 16k chunks but that we would retain in full if we were to slice even a single byte out of it in any position.