Some obvious speedups to parsing alias filters #127240
Conversation
It's in the title, saving some allocations and weird indirection in obvious spots.
original-brownbear
added
>non-issue
:Data Management/Indices APIs
elasticsearchmachine
added
v9.1.0
Team:Data Management
|
Pinging @elastic/es-data-management (Team:Data Management) |
| Predicate<String> isMatchAll = (((Predicate<String>) Metadata.ALL::equals)).or(Regex::isMatchAllPattern); | ||
| if (expressions == null | ||
| || expressions.length == 0 | ||
| || expressions.length == 1 | ||
| && (SelectorResolver.selectorsValidatedAndMatchesPredicate(expressions[0], context, isMatchAll))) { | ||
| && (SelectorResolver.selectorsValidatedAndMatchesPredicate( | ||
| expressions[0], | ||
| context, | ||
| s -> Metadata.ALL.equals(s) || Regex.isMatchAllPattern(s) | ||
| ))) { |
There was a problem hiding this comment.
Out of curiosity, hat's the value of inlining this variable?
There was a problem hiding this comment.
Metadata.all::equals and the .or call both actually allocate an object so this removes allocation outright (as well as some overhead for the method handles).
Also, the .or doesn't compile anything really, it just chains two predicates generically, unless that inlines we're just burning extra cycles for method calls vs a non-capturing lambda :)
| List<QueryBuilder> filters = Arrays.stream(aliases).map(key -> { | ||
| var f = dsAliases.get(key).getFilter(dataStreamName); | ||
| if (f == null) { | ||
| return null; | ||
| } | ||
| try { | ||
| return parseFilter(f.compressedReference()); | ||
| } catch (IOException e) { | ||
| throw new UncheckedIOException(e); | ||
| } | ||
| }).filter(Objects::nonNull).toList(); |
There was a problem hiding this comment.
What's the value of reordering these stream operations?
There was a problem hiding this comment.
We save one lookup on the aliases map by not doing an extra one just to null check :)
|
Thanks Niels! |
It's in the title, saving some allocations and weird indirection in obvious spots.