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:
David Roberts 2019-05-23 21:04:03 +01:00
parent 2b22ceac04
commit 14f29de2a8
1 changed files with 4 additions and 2 deletions

View File

@ -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() {