[
https://issues.apache.org/jira/browse/LOG4J2-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443958#comment-17443958
]
ASF subversion and git services commented on LOG4J2-3189:
---------------------------------------------------------
Commit cc298958343da4a2229550b0a2191a2b3963cab2 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=cc29895 ]
LOG4J2-3189: Improve worst-case NameAbbreviator performance
Previously the entire input string was written to the output
buffer, then small sections were deleted or replaced within that
string. This meant that for each section that was abbreviated,
nearly all following characters from subsequent sections would
be migrated, resulting in O(n^2) performance.
Now we read from the existing input String, and write sections
to the output buffer piece-by-piece. For small strings this may
result in more pointer-hopping (may cost ~tens of nanoseconds) while
larger values with many abbreviated sections are substantially
less expensive. I would expect large "enterprise-grade" class
names to perform better than previously.
Note that the new approach may result in multiple StringBuilder
resize operations in the worst case, where previously writing
the original string to the output would have caused it to grow
all at once. In most cases we attempt to initialize builders
with a reasonable size, so I opted not to add an `ensureCapacity`
given the estimated size may be substantially larger than we need.
> Improve NameAbbreviator worst-case performance
> ----------------------------------------------
>
> Key: LOG4J2-3189
> URL: https://issues.apache.org/jira/browse/LOG4J2-3189
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
> Affects Versions: 2.14.1
> Reporter: Carter Kozak
> Priority: Major
> Fix For: 2.15.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)