Avoid HashMap construction on Grok non-match (#42444)
This change moves the construction of the result HashMap in Grok.captures() into the branch that actually needs it. This probably will not make a measurable difference for ingest pipelines, but it is beneficial to the ML find_file_structure endpoint, as it tries out many Grok patterns that will fail to match.
This commit is contained in:
parent
2b22ceac04
commit
14f29de2a8
|
@ -240,7 +240,6 @@ public final class Grok {
|
|||
*/
|
||||
public Map<String, Object> captures(String text) {
|
||||
byte[] textAsBytes = text.getBytes(StandardCharsets.UTF_8);
|
||||
Map<String, Object> fields = new HashMap<>();
|
||||
Matcher matcher = compiledExpression.matcher(textAsBytes);
|
||||
int result;
|
||||
try {
|
||||
|
@ -256,6 +255,7 @@ public final class Grok {
|
|||
// TODO: I think we should throw an error here?
|
||||
return null;
|
||||
} else if (compiledExpression.numberOfNames() > 0) {
|
||||
Map<String, Object> fields = new HashMap<>();
|
||||
Region region = matcher.getEagerRegion();
|
||||
for (Iterator<NameEntry> entry = compiledExpression.namedBackrefIterator(); entry.hasNext();) {
|
||||
NameEntry e = entry.next();
|
||||
|
@ -270,8 +270,10 @@ public final class Grok {
|
|||
}
|
||||
}
|
||||
}
|
||||
return fields;
|
||||
} else {
|
||||
return Collections.emptyMap();
|
||||
}
|
||||
return fields;
|
||||
}
|
||||
|
||||
public static Map<String, String> getBuiltinPatterns() {
|
||||
|
|
Loading…
Reference in New Issue