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