Use zero page "holes" to optimize sparse byte array usage #108709
Merged
+106
−85
Conversation
This file contains 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
| for (int i = 0; i < pages.length; ++i) { | ||
| pages[i] = newBytePage(i); | ||
| Arrays.fill(pages, ZERO_PAGE); | ||
| assert assertZeroPageClean(); |
There was a problem hiding this comment.
Had some bugs with this, it's a little wasteful but having this in place lets me sleep better I think.
|
|
||
| protected byte[] getPageForWriting(int pageIndex) { | ||
| byte[] foundPage = pages[pageIndex]; | ||
| if (foundPage == ZERO_PAGE) { |
There was a problem hiding this comment.
This is the new overhead we add to the set path relative to not having this. It seems to me, that it's a trivial overhead, especially when considering that we're fine with lots of redundant reads in set today. Plus, I've never seen set hot in profiling.
| @@ -162,8 +164,8 @@ public BytesRef next() { | |||
| } | |||
|
|
|||
| @Override | |||
| public void fillWith(StreamInput in) throws IOException { | |||
| in.readBytes(array, 0, Math.toIntExact(size())); | |||
| public void fillWith(InputStream in) throws IOException { | |||
There was a problem hiding this comment.
See CCR changes, we were doing a really hacking thing there reading into a BytesReference via it's iterator over BytesRef. Just passing the ByteArray through the CCR code and reading via this method.
nik9000
approved these changes
May 17, 2024
| for (int i = 0; i < pages.length; ++i) { | ||
| pages[i] = newBytePage(i); | ||
| Arrays.fill(pages, ZERO_PAGE); | ||
| assert assertZeroPageClean(); |
|
Thanks Nik, 🤞 :) |
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
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.
Add the notion of a "zero page" or "hole" to big arrays. We have some use cases where we run up byte arrays of hundreds of MB that are extremely sparse.
Each page starts out as a "hole" and only gets replaced by a real page from the pool on write similar to how FS holes work.
This change adds a small amount of overhead to the write side but is performance neutral or better on the read side (for sparse arrays we likely get a big improvement from using less CPU cache).
The only change outside of the array itself this needed was in CCR, see inline comments for that.