[slf4j-user] Java 5 version of SLF4J?

[Ceki Gulcu]

Hi Simon,

Comments below.

Simon Kitching wrote:

 > Creating an object[] *after* the decision to log is made is no big
 > deal. The overheads of actually logging a message are much higher, so
 > passing the params is no longer significant. Only when one is created
 > *regardless* of whether logging occurs is there an issue.

+1

 > And BTW, I do agree with Ceki that pushing a couple of arguments
 > onto the stack is not a big deal. A push is quick, and cleaning up a
 > callstack afterwards is normally done in fixed-time, regardless of
 > what was on the stack. If params are passed in registers, it is even
 > quicker. So IMO, SLF4J's approach is fine from a performance
 > approach. Sorry if my mail wasn't clear on that.

+1

 > IMO, creating the Object[] is worth avoiding, however, which rules
 > out real varargs implemetations [1]. The cost is not just creating,
 > but also garbage-collection afterwards. Ceki and others made great
 > efforts to get the original log4j performance up (see the original
 > log4j page) and I'm sure he has put the same effort into logback. It
 > seems a shame to waste that unless the user benefits are significant..

I agree with the above. It is probably useful to note that Joern's
patch [1], does not change the existing method signatures, with one
exception.

BEFORE:

public interface Logger {

   public void debug(String msg);
   public void debug(String format, Object arg);
   public void debug(String format, Object arg1, Object arg2);
   public void debug(String format, Object[] argArray);
   public void debug(String msg, Throwable t);
   ... etc
}

After applying Joern's patch:

public interface Logger {

   public void debug(String msg);  // no change
   public void debug(String format, Object arg); // no change
   public void debug(String format, Object arg1, Object arg2); // no change
   public void debug(String format, Object... argArray); // CHANGE
   public void debug(String msg, Throwable t); // no change
   ... etc
}

Thus, Joern's patch has no impact on performance at all (compared to
SLF4J's Logger as it exists today).

 > The best solution of all is probably some kind of code-weaving, eg
 > http://just4log.sourceforge.net/ at build-time, or something similar
 > at runtime. Then projects can use any kind of API they want.

Most developers I know, including myself, hate magic. They/I consider
byte code manipulation as magic. That's the perception. I can't
imagine anyone accepting to see their .class files to be
post-processed just for log (pun intended).

So while just4log addresses an existing problem, its remedy may be
*perceived* to be worse that the illness.

 > [1] Unless the jvm is doing "escape analysis" as mentioned earlier
 > in this thread. I wonder how we could find out?
 > Simon

Interesting question. Don't have an answer.

Cheers,

[1] http://bugzilla.slf4j.org/attachment.cgi?id=21

-- 
Ceki Gülcü
QOS.ch is looking to hire talented developers in Switzerland.  If
interested, please contact c e k i AT q o s . c h