[
https://issues.apache.org/jira/browse/LOG4J2-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075890#comment-14075890
]
Remko Popma commented on LOG4J2-744:
------------------------------------
You are correct that this is happening, and I see how the patch would fix the
problem, but I am not sure yet if I want to apply the patch.
The patch proposes to use {{instanceof}} to check if the message is a
{{TimestampMessage}}, and avoid the call to {{clock.currentTimeMillis()}} if
that is the case.
This sometimes avoids the overhead of calling {{clock.currentTimeMillis()}},
but in return always adds the overhead of calling {{instanceof}}. I am aware
that {{instanceof}} is pretty damn fast nowadays, but I still hesitate to
optimize for TimestampMessages (a special case) at the expense of all other
message types...
I would like to do some performance testing first. If the cost of
{{clock.currentTimeMillis()}} is similar to {{instanceof}}, there may not be
much benefit, even for TimestampMessages.
> 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
