[ 
https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944679#comment-13944679
 ] 

Remko Popma commented on LOG4J2-547:
------------------------------------

Micro-benchmarks can be tricky stuff. Do you get the same results if you first 
measure bottom-up, then top-down? Or start with recurse(500), and work down to 
recurse(100)?

Things that make it tricky:
* avoid measuring during the first 3-10 seconds after the JVM started, as JVM 
initialization is still taking place in parallel
* Hotspot will compile "hot" code to native code. The default threshold is 
after 10,000 invocations. So in the example this will happen sometime while you 
are measuring.
* During compilation, hotspot will look at places to optimize. The loop can be 
unrolled, and statements in the loop re-ordered. If hotspot determines the code 
has no side-effects (doesn't change any state) and doesn't return a value, it 
may decide to optimize by simply not executing that code... Same results, but a 
lot faster. :-)

If you have time, please take a look at 
[JMH|http://openjdk.java.net/projects/code-tools/jmh/].
JHM is specifically designed to avoid these and other pitfalls.

> Update LoggerStream API
> -----------------------
>
>                 Key: LOG4J2-547
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-547
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.0-rc1
>            Reporter: Matt Sicker
>            Assignee: Ralph Goers
>             Fix For: 2.0-rc2
>
>         Attachments: 0001-PrintStream-API-update.patch, 
> PerfTestCalcLocation.java, log4j2-547-bbrouwer.patch, 
> log4j2-loggerStream.patch
>
>
> I've got some ideas on how to improve the LoggerStream idea that I added a 
> little while ago. The main thing I'd like to do is extract an interface from 
> it, rename the default implementation to SimpleLoggerStream (part of the 
> SimpleLogger stuff), and allow log4j implementations to specify a different 
> implementation if desired.
> In doing this, I'm not sure where specifically I'd prefer the getStream 
> methods to be. Right now, it's in Logger, but really, it could be in 
> LoggerContext instead. I don't think I should be required to get a Logger 
> just to get a LoggerStream.
> Now if only the java.io package used interfaces instead of classes. This 
> would be so much easier to design!



--
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