Skip to content

Conversation

@original-brownbear
Copy link
Contributor

Continuing to simplify this a little further:
No need to create the throttling CHM unless we actually are throttling, we can use the null to signal yes/no here.
Likewise, no need to have an extra mutex field on the failures reference, we can use the set-once reference.
Lastly, push down the building of the PIT id to the single place where it's actually used, that way we also save the transport version field that's only used in the PIT action on the parent class.

Continuing to simplify this a little further:
No need to create the throttling CHM unless we actually are throttling,
we can use the `null` to signal yes/no here.
Likewise, no need to have an extra mutex field on the failures reference, we can
use the set-once reference.
Lastly, push down the building of the PIT id to the single place where it's actually used, that way
we also save the transport version field that's only used in the PIT action on the parent class.
@original-brownbear original-brownbear added >non-issue :Search Foundations/Search Catch all for Search Foundations labels Apr 22, 2025
@elasticsearchmachine elasticsearchmachine added Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v9.1.0 labels Apr 22, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search-foundations (Team:Search Foundations)


protected final void performPhaseOnShard(final int shardIndex, final SearchShardIterator shardIt, final SearchShardTarget shard) {
if (throttleConcurrentRequests) {
var pendingExecutionsPerNode = this.pendingExecutionsPerNode;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why assign this to a local variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still faster than repeatedly accessing a field https://openjdk.org/jeps/8349536 :) Doesn't matter too much here, but I had a follow-up planned where some of these fields stop being final and get nulled out. I code up a bigger change and then break pieces out of it for review :) and while it's sort of an irrelelvant line here it avoids some git-history-churn and a trivial amount of CPU/memory work doing it this way I guess :D

Copy link
Contributor

@benchaplin benchaplin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks - looks good!

@original-brownbear original-brownbear added v8.19.0 auto-backport Automatically create backport pull requests when merged labels Apr 23, 2025
@original-brownbear
Copy link
Contributor Author

Thanks Ben!

@original-brownbear original-brownbear merged commit a3d3f9b into elastic:main Apr 23, 2025
17 checks passed
@original-brownbear original-brownbear deleted the simplify-state-abstract-search-async-action branch April 23, 2025 23:19
@elasticsearchmachine
Copy link
Collaborator

💔 Backport failed

Status Branch Result
8.x Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 127145

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-backport Automatically create backport pull requests when merged backport pending >non-issue :Search Foundations/Search Catch all for Search Foundations Team:Search Foundations Meta label for the Search Foundations team in Elasticsearch v8.19.0 v9.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants