[slf4j-user] is*Enabled vs explicit method call performance measure

[ceki]

One should usually use parametrized logging, the conditional form exists 
mostly for historical reasons.

-- 
Ceki
http://twitter.com/#!/ceki


On 11.11.2011 18:52, coldserenity wrote:
> (A small update just in case someone will ever need this)
>
> Recently I had to revisit the the rule “When dereferenced arguments are
> passed”.
> For complex cases like lazy loaded object or when some additional logic
> involved in method indeed we shall require is*Enabled check.
> However we have a lot of simple calls like “array.size()”,
> “System.currentTimeMillis() - start” so I wanted to know how big the
> overhead is without logging level check.
> I have prepared a  https://bitbucket.org/coldserenity/logperf/overview suite
> to test that, and it turned out that on 500 Million iterations on my
> Corei5+4GB1333DDR3 PC
>     “if (isDebugEnabled())” averages to 2.1seconds while
>      “array.size()” to 3.7s and
>     “System.currentTimeMillis() - start” to 10.9s.
> As you can see those are WITHIN the same order of magnitude. Which means we
> can quite safely use explicit calls for those two and similar cases, where
> we would have used isDebugEnabled() check. Just to underline how miserable
> the difference is I’ll explain what 500M iterations mean. In this test they
> are lines in the log file should we turn the debugging on. With an average
> of 80 characters per line (which is usually greater) we would have received
> a 40Gigabyte per 10 seconds for log file growth may the HDD allow us writing
> at such speeds. Of course not all logs are turned at once; however neither
> is the application flow happening at such speeds (side-note out of this is
> that for critical application blocks (million-iteration loops) there should
> be no logging statements at all).
>
> So to conclude, I now tend to think that there can be no edge-case rule
> either to solely use or not to use if (isDebugEnabled()) statements. A
> developer must understand the background (whether this is critical execution
> path or not, is the logic overly-complex to understand, what is the
> performance impact of particular statement as compared to alternatives, the
> consequences of taking one or the other approach) and make the decision
> consciously – as a balance between code readability (maintainability) and
> performance.
>
>