Joern Huxhorn schrieb: > > Ceki Gulcu wrote: > > > >> >> Joern Huxhorn wrote: >> >> >> >>> >>> Simon Kitching wrote: >>> >>> >>> >>>> >>>> The SLF4J fake-varargs approach, where the api allows 0,1 or 2 params >>>> >>>> is >>>> >>>> slightly better, as it avoids the "new Object[]" call. But for best >>>> >>>> performance, isDebugEnabled should be used anyway. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Simon >>>> >>>> >>>> >>> >>> Hi Simon. >>> >>> >>> >>> The above isn't the case for logback since calls with explicit >>> >>> arguments >>> >>> (instead of argument array) are simply wrapped in an Object[] and >>> >>> forwarded to the Object[]-implementation of the method. >>> >>> >>> >>> Joern. >>> >>> >>> >> >> Hello Joern, Hello Simon, >> >> >> >> >> >> I just quickly looked at the code and I believe that parameters are >> >> aggregated into Object[] *after* a decision is made to log. Filters in >> >> appenders may override this decision, but that happens much later in >> >> the processing pipeline. >> >> >> >> As for Simon's argument that the extra parameters need to be pushed >> >> onto the execution stack, I think that pushing one or two arguments >> >> onto the stack takes about or less than a nanosecond on most machines, >> >> hardly noticeable even if you log millions of times a second. >> >> Creating an Object[] takes about 20 nanoseconds, a lot more than >> >> pushing a parameter but still only 20 nanoseconds. >> >> >> >> Cheers, >> >> >> >> >> > > > > Hi Ceki. > > > > I didn't mean to imply that anything is wrong or inefficient with the > > current implementation in Logback. I only meant that an Object[] *is* > > created after the decision if logging should actually happen - which is > > absolutely necessary anyway because LoggingEvent needs the parameters in > > an Object[] anyway. > > > > It's just not the case - and I thought that's what Simon was thinking - > > that there is a special, optimized version of the logging methods that > > do not use an Object[] at all. > > > 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.
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. 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.. 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. [1] Unless the jvm is doing "escape analysis" as mentioned earlier in this thread. I wonder how we could find out? Regards, Simon _______________________________________________ user mailing list user@slf4j.org http://www.slf4j.org/mailman/listinfo/user
