[ 
https://issues.apache.org/jira/browse/LOG4J2-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Harrington updated LOG4J2-744:
------------------------------------

    Attachment: ClockBenchmark-jdk1.7.0_45.txt

Summary of results for Java 7 (full JMH output attached). Looks like the 
'instanceof' downcast adds about 10-20ns to a 85-125ns Log4jLogEvent 
constructor. Ignore CachedClock which seems to suffer from thread contention (I 
configured this JMH run to use 4 threads).

CentOS 6.5 on E5-2667 v2 @ 3.30GHz

{noformat}
Benchmark                                                                   
Mode   Samples         Mean   Mean error    Units
o.a.l.l.p.j.ClockBenchmark.testBaseline                                   
sample    238251       27.986        0.132    ns/op
o.a.l.l.p.j.ClockBenchmark.testCachedClockSimpleMessage                   
sample    265004      546.528        2.022    ns/op
o.a.l.l.p.j.ClockBenchmark.testCachedClockSimpleMessageNoDowncast         
sample    265057      192.856        0.531    ns/op
o.a.l.l.p.j.ClockBenchmark.testCachedClockTimestampMessage                
sample    278932       65.167        0.191    ns/op
o.a.l.l.p.j.ClockBenchmark.testCoarseCachedClockSimpleMessage             
sample    358047       85.017        0.122    ns/op
o.a.l.l.p.j.ClockBenchmark.testCoarseCachedClockSimpleMessageNoDowncast   
sample    366842       84.530        0.168    ns/op
o.a.l.l.p.j.ClockBenchmark.testCoarseCachedClockTimestampMessage          
sample    255360       69.229        0.208    ns/op
o.a.l.l.p.j.ClockBenchmark.testFakeClockSimpleMessage                     
sample    272217      105.782        0.199    ns/op
o.a.l.l.p.j.ClockBenchmark.testFakeClockSimpleMessageNoDowncast           
sample    365182       85.052        0.165    ns/op
o.a.l.l.p.j.ClockBenchmark.testFakeClockTimestampMessage                  
sample    286814       65.450        0.282    ns/op
o.a.l.l.p.j.ClockBenchmark.testOrdinaryLogEvent                           
sample    199051      136.273        0.277    ns/op
o.a.l.l.p.j.ClockBenchmark.testSystemClockSimpleMessage                   
sample    297985      135.690        0.312    ns/op
o.a.l.l.p.j.ClockBenchmark.testSystemClockSimpleMessageNoDowncast         
sample    235139      124.363        0.176    ns/op
o.a.l.l.p.j.ClockBenchmark.testSystemClockTimestampMessage                
sample    290519       64.377        0.231    ns/op
{noformat}


> 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-jdk1.7.0_45.txt, 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]

Reply via email to