[
https://issues.apache.org/jira/browse/LOG4J2-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Harrington updated LOG4J2-744:
------------------------------------
Attachment: ClockBenchmark.java
Drop the attached file into
log4j-perf/src/main/java/org/apache/logging/log4j/perf and then 'mvn install'
in log4j-perf and run the multi-thread test command line I put into the class
comment. Feel free to add more/different tests.
It may turn out that neither the Clock or instanceof are very significant
compared to the ThreadLocal accesses for ContextMap and ContextStack. However
these things all add up so I agree it's bad to make everyone pay the
'instanceof' penalty (however small) if an API revision (to be debated) could
make it work better for everyone.
I'm running it now and will attach my results.
> Avoid unnecessary Clock calls when TimestampMessage is logged
> -------------------------------------------------------------
>
> Key: LOG4J2-744
> URL: https://issues.apache.org/jira/browse/LOG4J2-744
> Project: Log4j 2
> Issue Type: Improvement
> Reporter: Scott Harrington
> Priority: Minor
> Attachments: ClockBenchmark.java, LOG4J2-744-test.patch,
> LOG4J2-744.patch
>
>
> The TimestampMessage interface was introduced in LOG4J2-53 and revised for
> AsyncLogger in LOG4J2-455.
> I've observed that Clock.currentTimeMillis is still called which should not
> be necessary.
> I have two patches, one which adds JUnit tests that demonstrate the
> unnecessary Clock calls, and one which fixes the issue for both AsyncLogger
> and "traditional" configurations.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
