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 _______________________________________________ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user