-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Cache buckets to speed up BytesRefHash#sort #12784
Conversation
Even faster than the original approach on M2:
|
As "reorder" gets faster, I'm considering lowering the fallback threshold and letting radix sort do more of the work. MAC Intel
MAC M2
|
I try this approach with MAC Intel
MAC M2
|
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.
This is a fantastic speedup. The change looks correct to me. I would not have expected caching buckets to help that much, it's great you thought of trying it out.
Did we see any bump in nightly benchmarks? This should make initial segment flush when there are many terms in an inverted field faster? |
Thanks for tracking in ! @mikemccand
I would expect this change more likely bring some improvements for flushing high cardinality However, I had not expected this change would bring a bump in nightly benchmarks - If you look at the CPU profile of the nightly indexing, you may find that most of CPU was used to tokenize / deduplicate terms before flushing. After deduplication the terms count will get reduced and the sort is not the bottleneck of the indexing speed (sort only use ~1% CPU). Small difference may be found in the flame graph that |
Following #12775, this PR tries another approach to speed up
BytesRefHash#sort
:The idea is that since we have extra ints in this map, we can cache the bucket when building the histograms, and reuse them when
reorder
. I checked this approach on intel chip, showing ~30% speed up. I'll check M2 chip and wikimedium data tomorrow.