On Dec 10, 2008, at 11:36 AM, Ceki Gulcu wrote:
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.
For a short message of 25 letters, on my machine, LogMF.format(String,
Object) takes 7.5 microseconds, while the SLF4J formatter takes 1
microsecond. Thus, there is a ratio of 7.5 to 1 in performance.
Given that it takes 5 to 10 microseconds to write a logging event to
file, the LogMF overhead is significant.
To repeat the experiment:
> svn co http://svn.apache.org/repos/asf/logging/log4j/companions/extras/trunk/
extras
> modify LogMF.format(String pattern, Object arg0) method as public
instead of private
> mvn package -Dmaven.test.skip=true
> Add slf4j-api-1.5.6.jar and apache-log4j-extras-1.1-SNAPSHOT.jar
(that you just built) to you class path.
> Run the following unit test
package test;
import org.apache.log4j.LogMF;
import org.junit.Test;
import org.slf4j.helpers.MessageFormatter;
public class XTest {
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);
@Test
public void testLogMF() {
for(int i = 0; i < LEN; i++ ){
LogMF.format(MSG_2, x);
}
long start = System.nanoTime();
for(int i = 0; i < LEN; i++ ){
LogMF.format(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++ ){
MessageFormatter.format(MSG, x);
}
long start = System.nanoTime();
for(int i = 0; i < LEN; i++ ){
MessageFormatter.format(MSG, x);
}
long end = System.nanoTime();
System.out.println("SLF4J avg="+ (end-start)/LEN);
}
On my machine the output is:
LogMF avg=7568
SLF4J avg=1021
Thus, contrary to your claim, LogMF does *not* offer equivalent
performance to SLF4J's formatter.
As I remember, my benchmarks were very, very low overhead logging
calls (NullAppender or the like) or less than threshold logging calls
and the performance between the formatters was totally lost in the
NullAppender overhead. It was several years ago, so I'll have to dig
in the archives.
The SLF4J formatting style, altough not the same as the JDK's, is
easier to type (try it) and less error prone (you can't get the
numbers wrong because there are none). More importantly, SLF4J users
love it.
The numbers are very useful if you are dealing with
internationalization (as the previous link which was almost one of the
first feedback items on slf4j-dev). Maybe some users love no indexes,
others find them useful.
Instead of trying to re-invent the wheel, we, as log4j developers,
would do the java developer community a favor by adopting SLF4J, a
popular and stable API. As mentioned on several occasions by now,
there is also a way to conserve 100% compatibility for existing
log4j clients.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
