Optimize DataTierAllocationDecider Further#78235
Optimize DataTierAllocationDecider Further#78235original-brownbear merged 3 commits intoelastic:masterfrom original-brownbear:more-fixes-data-tier-alloc-decider
Conversation
This decider is still by far the most expensive component of reroute operations. Optimizing away some more costly allocations and slow stream loops.
|
Pinging @elastic/es-data-management (Team:Data Management) |
henningandersen
left a comment
There was a problem hiding this comment.
LGTM, except for the regexp use.
| } else { | ||
| String[] split = value.split(","); | ||
| if (Arrays.stream(split).anyMatch(DATA_FROZEN::equals)) { | ||
| if (FROZEN_TIER_PATTERN.matcher(value).find()) { |
There was a problem hiding this comment.
I am not really sure about this bit, might run faster, might not?
Perhaps we can add a test validating that just doing value.indexOf(DATA_FROZEN) is safe, i.e., that there are no other tiers starting with DATA_FROZEN?
There was a problem hiding this comment.
Jup see d62ad36 that should be much faster and is more fun to read as well :)
|
Thanks Henning! |
dakrone
left a comment
There was a problem hiding this comment.
I know this is already merged, but I left a comment about behavior that this changes
.../main/java/org/elasticsearch/xpack/cluster/routing/allocation/DataTierAllocationDecider.java
Show resolved
Hide resolved
|
My other concern about this is that without any code comments about why these changes were made, we run the risk of accidentally undoing these changes in a subsequent PR. (something like "oh, I like streams, I'll use those rather than this old |
This decider is still by far the most expensive component of reroute operations on very large clusters.
Optimizing away some more costly allocations and slow stream loops.