-
Notifications
You must be signed in to change notification settings - Fork 982
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor ByteBlockPool so it is just a "shift/mask big array" #12625
Conversation
Yay, TODO mining for the win :) We should scour our TODOs more often! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On quick pass this looks great! We are pulling the hairy BytesRef
packing logic apart from the "just store a paged byte[]" logic. Thank you @iverase! Have you tested luceneutil
to see if there's any performance change?
lucene/core/src/java/org/apache/lucene/util/BytesRefBlockPool.java
Outdated
Show resolved
Hide resolved
I run luceneutil for wikimedium10m and I don't think it shows any slow down (I find hard to understand the output):
|
Hmm, surprisingly noisy, especially for the biggest regression and anti-regression. Did this run for the full 20 iterations? Maybe re-run with Actually, sorry, this change should only impact indexing, I think? We only use this (complex) memory store to store interleaved slices of postings lists? I think it's fine to leave this to the nightly benchmarks -- let's watch after pushing if they catch any slowdown. This is otherwise a rote refactoring (separating the logic of packed |
I run wikimediumall and still a bit noisy:
There has been some changes that might affect lucene bench so I will wait until waters are calmer to push this change and monitor the benches. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @iverase! I was working on something similar in #12506. There are a few differences between our PRs.
You address the BytesRef
methods, while I addressed a few other clean-up items.
We both moved the slice functionality out of ByteBlockPool
. What do you think of making a class like ByteSlicePool
to separte concerns from other TermsHashPerField
functionality?
Overall, we could do the slices and BytesRef
in this PR and I'll try to rebase #12506 after or we can try to merge the two PRs now.
*/ | ||
// pkg private for access by tests | ||
static int newSlice(ByteBlockPool bytePool, final int size, final int level) { | ||
assert LEVEL_SIZE_ARRAY[level] == size; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this - why pass in both size and level if we assert that one can be deduced from the other?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is just a micro optimization to avoid looking twice into the array. This is a copy paste of the original code.
Moved all the hairy allocSlice stuff as static method in TermsHashPerField and I introduce a BytesRefBlockPool to encapsulate of the BytesRefHash write/read logic.
This sounds compelling to me. The byte slicing/interleaving is complex enough to be self contained and separated from both
Hmm it looks like this PR was merged already, so I guess @stefanvodita we should continue your ideas in #12506. Very exciting that two devs are suddenly interesting in improving this complex low level code -- thanks! |
…ache.org * upstream/main: (239 commits) Bound the RAM used by the NodeHash (sharing common suffixes) during FST compilation (apache#12633) Fix index out of bounds when writing FST to different metaOut (apache#12697) (apache#12698) Avoid object construction when linear searching arcs (apache#12692) chore: update the Javadoc example in Analyzer (apache#12693) coorect position on entry in CHANGES.txt Refactor ByteBlockPool so it is just a "shift/mask big array" (apache#12625) Extract the hnsw graph merging from being part of the vector writer (apache#12657) Specialize `BlockImpactsDocsEnum#nextDoc()`. (apache#12670) Speed up TestIndexOrDocValuesQuery. (apache#12672) Remove over-counting of deleted terms (apache#12586) Use MergeSorter in StableStringSorter (apache#12652) Use radix sort to speed up the sorting of terms in TermInSetQuery (apache#12587) Add timeouts to github jobs. Estimates taken from empirical run times (actions history), with a generous buffer added. (apache#12687) Optimize OnHeapHnswGraph's data structure (apache#12651) Add createClassLoader to replicator permissions (block specific to jacoco). (apache#12684) Move changes entry before backporting CHANGES Move testing properties to provider class (no classloading deadlock possible) and fallback to default provider in non-test mode simple cleanups to vector code (apache#12680) Better detect vector module in non-default setups (e.g., custom module layers) (apache#12677) ...
I've rebased #12506. I like having a separate class for slice allocation, but if there's disagreement over that, I can put the code back in |
Thanks @stefanvodita -- I'll try to have a look soon at your rebased PR #12506. And thank you for gracefully handling the "two people made very similar changes" situation :) This happens often in open source, but it's actually a good thing since you get two very different perspectives and the final solution is best of both. |
While working in the code base I stumble with this TODO and this issue so I give it a try to simplify ByteBlockPool so it does not contain specific logic for terms.
The result here is that I moved all the hairy allocSlice stuff as static method in TermsHashPerField and I introduce a BytesRefBlockPool to encapsulate of the BytesRefHash write/read logic.
I updated javadocs accordingly.