[
https://issues.apache.org/jira/browse/LOG4J2-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540690#comment-16540690
]
ASF GitHub Bot commented on LOG4J2-2373:
----------------------------------------
Github user cakofony commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/190#discussion_r201843300
--- Diff:
log4j-api/src/main/java/org/apache/logging/log4j/util/StringBuilders.java ---
@@ -169,53 +169,85 @@ public static void trimToMaxSize(final StringBuilder
stringBuilder, final int ma
}
public static void escapeJson(final StringBuilder toAppendTo, final
int start) {
- for (int i = toAppendTo.length() - 1; i >= start; i--) { //
backwards: length may change
+ int escapeCount = 0;
+ for (int i = start; i < toAppendTo.length(); i++) {
final char c = toAppendTo.charAt(i);
switch (c) {
case '\b':
- toAppendTo.setCharAt(i, '\\');
- toAppendTo.insert(i + 1, 'b');
+ case '\t':
+ case '\f':
+ case '\n':
+ case '\r':
+ case '"':
+ case '\\':
+ escapeCount++;
+ break;
+ default:
+ if (Character.isISOControl(c)) {
+ escapeCount += 5;
+ }
+ }
+ }
+
+ int lastChar = toAppendTo.length() - 1;
+ toAppendTo.setLength(toAppendTo.length() + escapeCount);
+ int lastPos = toAppendTo.length() - 1;
+
+ for (int i = lastChar; i >= start; i--) {
--- End diff --
I think we can change the condition from `i >= start` to `lastPos > i`. On
the fast path there's nothing to escape, so this loop should be a no-op. This
allows us to stop iterating once we've escaped the last unescaped character.
> StringBuilder escapeJson performs unnecessary Memory Allocations
> ----------------------------------------------------------------
>
> Key: LOG4J2-2373
> URL: https://issues.apache.org/jira/browse/LOG4J2-2373
> Project: Log4j 2
> Issue Type: Bug
> Reporter: Kevin Andrew Meurer
> Priority: Major
>
> The StringBuilders.escapeJson function currently uses the string builder's
> insert method to add elements to an existing builder for the purposes of
> escaping special characters. Unfortunately, this leads to a loop that
> regularly expands the builder capacity, causing issues at scale.
> A better approach would do a first run through to compute the total space
> required for the addition and then fill that space using the current method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
