Use fast path for 0 or 1-segment searches #113969
Open
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
We can short-circuit both the 0 and and 1-segment use cases. For zero segments, we can skip rewrite and weight cration, for a single segment we can fully bypass the `TaskExcecutor` overhead and save a couple of memory barriers.
original-brownbear
added
>non-issue
:Search Foundations/Search
elasticsearchmachine
added
v9.0.0
Team:Search Foundations
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
|
|
||
| @Override | ||
| public Query rewrite(IndexSearcher indexSearcher) throws IOException { | ||
| maybeThrow(context); |
There was a problem hiding this comment.
Had to adjust this since some tests without data started failing on account that we weren't creating the weight any longer.
|
We discussed a similar change in #111126 , I am not convinced this is the way to go. I'd like to better understand the motivations. To be clear, I don't like that these methods that we override from plain Lucene diverge that much from their original implementation. These to me are forks that we should strive to remove over time, as opposed to optimizing them. |
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.
Partly motivated by the desire to have a clearly identifiable code path for non-concurrent search execution in profiling, but does save a couple of cycles and an equivalent fix in Lucene (I'll open a PR as well) yields a measurable speedup.
We can short-circuit both the 0 and and 1-segment use cases. For zero segments, we can skip rewrite and weight creation, for a single segment we can fully bypass the
TaskExecutoroverhead and save a couple of memory barriers.Also, we can save building the intermediary
Collectorlist and simply create the tasks right away.