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

Bruce Brouwer updated LOG4J2-547:
---------------------------------

    Attachment: MyBenchmark.java

I took a stab at JMH. When I pulled out the code that actually takes the stack 
trace (using a pre-generated stack trace) and left only the iterating code, it 
shows the current code to be *much* faster. However, when you throw in the 
generation of the stack trace, it looks like it becomes inconsequential. Here 
are the results for a stack trace that is 200 entries deep. 
{code}
Benchmark                    Mode   Samples         Mean   Mean error    Units
o.s.MyBenchmark.bottomUp    thrpt       200        6.923        0.036   ops/ms
o.s.MyBenchmark.topDown     thrpt       200        6.913        0.034   ops/ms
{code}
I've attached the benchmark code, too as {{MyBenchmark.java}}. This could be 
skewed somewhat as part of this time is spent making a recursive call of 208 
methods deep just to make the call to build the stack trace, but I wasn't 
coming up with a better way to generate the stack trace and have it be part of 
the benchmark results. 

> 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, MyBenchmark.java, 
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to