[
https://issues.apache.org/jira/browse/LOG4J2-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406866#comment-17406866
]
ASF subversion and git services commented on LOG4J2-3153:
---------------------------------------------------------
Commit 5078db0e90e2862d2027457f0e95ccb8dbd221fb in logging-log4j2's branch
refs/heads/master from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=5078db0 ]
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)
