[
https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Brouwer updated LOG4J2-547:
---------------------------------
Attachment: PerfTestCalcLocation.java
I decided to run a quick performance test. You can see the tester code in
{{PerfTestCalcLocation.java}}, which I attached. The alternate {{calcLocation}}
code I wrote looks like this (which is actually much simpler than the current
code:
{code}
public static StackTraceElement calcLocation2(final String fqcnOfLogger) {
if (fqcnOfLogger == null) {
return null;
}
final StackTraceElement[] stackTrace =
Thread.currentThread().getStackTrace();
// start 2 below, just in case the last entry happens to match the FQCN
for (int i = stackTrace.length - 2; i >= 0; i--) {
if (fqcnOfLogger.equals(stackTrace[i].getClassName())) {
return stackTrace[i + 1];
}
}
return null;
}
{code}
And here are the performance results:
{code}
10 deep: Top-down: 83653 ops/sec, bottom-up: 86745 ops/sec, -3.5644684% slower
50 deep: Top-down: 24557 ops/sec, bottom-up: 24033 ops/sec, 2.180336% slower
100 deep: Top-down: 12854 ops/sec, bottom-up: 12927 ops/sec, -0.5647125% slower
200 deep: Top-down: 6640 ops/sec, bottom-up: 6640 ops/sec, 0.0% slower
500 deep: Top-down: 2623 ops/sec, bottom-up: 2630 ops/sec, -0.26615906% slower
{code}
It appears that the direction we traverse the stack trace has negligible impact
on the performance, no matter how deep the stack trace. I've never seen the
results go above 3% slower over multiple runs, and often, it shows it going
faster.
So if performance is the only concern, I kind of like the idea of switching to
the bottom-up approach.
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
