[
https://issues.apache.org/jira/browse/LOG4J2-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075937#comment-14075937
]
Remko Popma commented on LOG4J2-744:
------------------------------------
Gary, interesting question... I'm not sure actually. My guess would be yes, but
would need to measure to be sure.
However, it if is okay to add a method to the Message interface, I would prefer
to add a method {{Message.getTimestamp(IClock)}}. Most messages would return
clock.currentTimeMillis(), but TimestampMessages would return
this.getTimestamp(). Performance-wise this would be ideal since it would
eliminate the need for conditional branching.
(On the other hand, I don't think this use case is strong enough to justify an
API change.)
> Aviod 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: 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
