On Dec 9th 2008 16:57 GMT Curt Arnold wrote:
> The supposed performance benefit of the SLF4J formatter over the
> java.text.MessageFormat only occurs when you compare the performance
> against naive use of java.text.MessageFormat. LogMF handles the
> simplest pattern specifications (those just involving {0}, {1}, etc)
> internally and only delegates to java.text.MessageFormat for more
> complex pattern specifications, resulting in equivalent performance to
> the SLF4J formatter on functionally equivalent format specifiers while
> still supporting the full java.text.MessageFormat capabilities.
On Dec 11, 2008, at 9:04 AM, Ceki Gulcu wrote:
> There is no point in digging into into the archives. Unless you can
> point to a mistake in the test case I provided yesterday, it
> irrefutably demonstrates that LogMF does not offer equivalent
> performance.
On Dec 11, 2008, at 9:04 AM, Curt Arnold wrote:
> You are using a private method in a totally artificial manner and no
> comparison with the overhead of creating a LoggingEvent etc. Maybe
> outside the context of a logging request the performance difference
> was significant, but the performance difference could be dwarfed by
> the expense of creating a LoggingEvent or some other fixed cost.
My use the format method (a private method) in LogMF is not "totally
artificial". It directly compares the LogMF formatter with the SLF4J
formatter, irrefutably demonstrating that the SLF4J formatter is 7.5
times faster than the LogMF formatter. It would have been nice for you
to acknowledge that fact. Instead, you are now arguing that the
performance difference does not matter. You write:
> I will explain why I've not been fully involved in this thread in very
> short order. Please realize that I spent a large amount of time on
> this list several years ago discussing with the community and provided
> many benchmarks at that time. I recall it did not show any detectable
> difference due to SLF4J-style format and MessageFormat in the context
> of either a trivial appender or a lower than threshold request. Maybe
> there very well could be a slight difference in performance of the
> formatter, but if it is dwarfed by other unavoidable costs (creation
> of a LoggingEvent for example), then the relative difference would
> never be noticed.
Instead of comparing the formatting methods, we can compare the time
it takes to log into a file. I am not talking about NullAppender but a
bona fide FileAppender. Here is the code:
package test;
import org.apache.log4j.LogMF;
import org.apache.log4j.Logger;
import org.junit.Test;
import org.slf4j.LoggerFactory;
public class YTest {
static int LEN = 100000;
final static String MSG = "Hello Hello Hello Hello {}";
final static String MSG_2 = "Hello Hello Hello Hello {0}";
Integer x = new Integer(1);
Logger log4jLogger = Logger.getLogger(YTest.class);
org.slf4j.Logger slf4jLogger = LoggerFactory.getLogger(YTest.class);
@Test
public void testLogMF() {
for (int i = 0; i < LEN; i++) {
LogMF.debug(log4jLogger, MSG_2, x);
}
long start = System.nanoTime();
for (int i = 0; i < LEN; i++) {
LogMF.debug(log4jLogger, MSG_2, x);
}
long end = System.nanoTime();
System.out.println("LogMF avg=" + (end - start) / LEN);
}
@Test
public void testSLF4J() {
for (int i = 0; i < LEN; i++) {
slf4jLogger.debug(MSG, x);
}
long start = System.nanoTime();
for (int i = 0; i < LEN; i++) {
slf4jLogger.debug(MSG, x);
}
long end = System.nanoTime();
System.out.println("SLF4J avg=" + (end - start) / LEN);
}
}
Here is the log4j.properties configuration file:
log4j.rootLogger=debug, FILE
log4j.appender.FILE=org.apache.log4j.FileAppender
log4j.appender.FILE.File=ytest.log
log4j.appender.FILE.BufferedIO=true
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d %p %c - %m%n
To run this test, in addition to junit4.jar, you need to have
slf4j-api.jar, apache-log4j-extras-1.1-SNAPSHOT.jar and log4j.jar on
your class path.
On my machine the output is:
LogMF avg=15251
SLF4J avg=4964
This shows that an enabled logging statement runs three times faster
when logging via SLF4J than when logging through LogMF, with log4j as
the underlying logging framework. Not only is the SLF4J formatter
faster, it makes a "noticeable" difference when the logs are actually
written to destination.
In conclusion, assuming the last two tests I provided are error-free,
they establish that not only the SLF4J formatter is faster, this
difference is clearly noticeable by the end-user.
> There are many features that java.text.MessageFormat has that the
> SLF4J formatter does not have. Even if there is a substantial
> performance difference, there may be cases where you would want to use
> MessageFormat or java.util.Formatter in spite of performance
> differences. The LogMF and LogSF approach allows users to pick which
> formatter best suits their needs. The SLF4J approach enforces a
> choice of a particular formatter over any other formatter.
The SLF4J formatter indeed exposes one formatter in a convenient
way. However, it does not preclude extending SLF4J in the way LogMF
extends log4j. Not only such extensions are possible, they already
exist [1]. However, SLF4J caters for the most common case in a
convenient way. I don't have a marketing survey to prove this, but if
you use the SLF4J API, even for a short while, you'll see what I mean.
> There is a substantial community that depends on log4j 1.x remaining
> 100% compatible with their existing code that used log4j 1.x features
> in the expected and normal way. It is a disservice to them to release
> any log4j 1.x that breaks their perfectly valid app. Several years
> ago there was not an identified way to directly support SLF4J without
> breaking compatibility with any app that used a non-String message and
> without making a maintenance release add a dependency on an alpha or
> beta jar. Maybe your new proposal addresses the compatibility issue
> and SLF4J is fixed, but there has not been any time to prepare an
> exploratory project in the sandbox to confirm your suggested approach
> and to evaluate the consequences.
Let me remind you that UGLI (the predecessor of SLF4J) was 100%
compatible with log4j. The String incompatibly issue arose later,
after it became clear that log4j was not interested in UGLI (because
it was not yet proven). But I am digressing.
With respect to an exploratory project, I can set it up under
https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_LOG4JS
> In my earlier discussion about the ASF and log4j brand, my intention
> was not denigrate your role in founding the project or try to claim
> responsibility for your work. It is just that a users expectation
> from the Apache and log4j brand is that Apache does not break
> compatibility on dot releases and log4j 1.x+1 is compatible with log4j
> 1.x. There is no expectation that logback, nlog4j, slog4j, log4j 2 or
> any other designation is binary and source compatible with log4j
> 1.x. There is an expectation that log4j 2 will address locking issues
> and use Java 5 idioms. If there is a log4j variant that supports
> SLF4J but is not compatible with log4j 1.x, I'd strongly prefer using
> a different name but synchronizing the version numbers so that slog4j
> 1.2.18 would be a variant of log4j 1.2.18 that was mostly log4j
> compatible but supported SLF4J.
I think it is fair to say that Apache, as a foundation, does not care
about log4j version designations. Log4j committers can decide about
the future of log4j without deferring to the board or worrying about
the Apache brand. As long as we can get our shit together here, the
foundation is likely to be supportive of whatever we decide, including
backward incompatible changes. Of course, that does not mean we
should, it means we can. But I am digressing.
As log4j committers, our job is to respond to user demand. Log4j
committers would do the larger java developer community a valuable
service by helping in java logging disambiguation. I don't think
log4js is the answer. Java logging does not need more choice. It needs
consolidation.
The current java logging mess is not good for anyone, including
log4j. As such, I consider log4js as only a start. In the long run,
log4js and log4j should be merged.
> However, all that is labeling issues for code that we have not seen or
> written.
True. I'll get the ball rolling so that you will have code to look
at.
[1] http://bugzilla.slf4j.org/show_bug.cgi?id=116
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
