-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Use radix sort to speed up the sorting of deleted terms #12573
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
Conversation
jpountz
left a comment
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.
Nice! I left some minor comments but it looks great in general.
lucene/core/src/java/org/apache/lucene/index/BufferedUpdates.java
Outdated
Show resolved
Hide resolved
lucene/core/src/java/org/apache/lucene/index/BufferedUpdates.java
Outdated
Show resolved
Hide resolved
jpountz
left a comment
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.
LGTM. I like that it also makes buffered deletes more memory-efficient as a side-effect.
|
Thanks @jpountz ! |
Description
Recently, we captured a flame graph in a scene with frequent updates, which showed that sorting deleted terms occupied a high CPU ratio.
In scenarios with many deleted terms, most terms could have the same field name. So a data structure like
Map<String, Map<BytesRef, Integer>>instead ofMap<Term, Integer>could be better here —— We can avoid field name compare and useMSBRadixSortto sort the bytes for each field.We can also take advantage of
BytesRefHashto implementMap<BytesRef, Integer>to get a more efficient memory layout, and there's already aMSBRadixSortimpl inBytesRefHashwe can reuse.Benchmark
We benchmarked the sort logic for 1,000,000 terms, showing 66% took decreasing:
An E2E benchmark that delete document with term 1,000,000 times showing took decreased 43% (with default iw config).