[
https://issues.apache.org/jira/browse/LOG4J2-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406865#comment-17406865
]
ASF subversion and git services commented on LOG4J2-3153:
---------------------------------------------------------
Commit 7868911351273509b7188efa19b408e3695a6448 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=7868911 ]
LOG4J2-3153: PreciseClock doesn't impact DatePatternConverter performance
Cached values are not invalidated for microsecond changes when
only milliseconds are needed. This is a relatively naive approach
which specifically targets microsecond vs millisecond precision
and has no additional impact on less precise date formats, however
FixedDateFormat has a fixed set of supported formats, all of which
use either 3, 6, or 9 second decimal points.
> FixedDateFormat performs poorly with a PreciseClock
> ---------------------------------------------------
>
> Key: LOG4J2-3153
> URL: https://issues.apache.org/jira/browse/LOG4J2-3153
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
> Affects Versions: 2.14.1
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
>
> Enabling a PreciseClock with microsecond precision (default on jdk9+) results
> in substantially worse performance in DatePatternConverter using a
> FixedDateFormat which doesn't rely on microsecond precision.
> The cached value is invalidated every time the microsecond clock changes.
> This is correct when the clock uses microsecond precision, however many
> configurations (including the default) use only millisecond precision, so we
> can reuse the cached value many times longer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
