--- Comment #2 from Alexis Giotis <> 2011-11-21 21:14:00 
UTC ---
Hi Vincent, 

I guess you are referring to the removed lines in During
the tests, I had disabled most of the logging by setting the log4j priority to
WARN for all categories. Normally, a negligible impact is expected but
profiling with VisualVM showed the following stacktrace taking a measurable
time, I think about 2% :

    at org.apache.log4j.Category.getEffectiveLevel(
    at org.apache.log4j.Category.isEnabledFor(
If I was investigating a FOP issue and I needed this kind of trace information,
I would most likely use a debugger. If the trace messages seem useful &
changing the logging configuration at runtime is not important, then one could
alternatively declare & use:

private static final boolean isTraceEnabled = log.isTraceEnabled();

The o.a.l.Category.getEffectiveLevel()  searches the category hierarchy for a
non-null level and returns it. Logback, the intended successor of log4j by the
very same authors, has a faster overall implementation. Still according to

"When logging is turned off entirely, the cost of a log request consists of a
method invocation plus an integer comparison. On a 3.2Ghz Pentium D machine
this cost is typically around 20 nanoseconds."

Therefore, completely removing some trace messages from 'hotspots' seems a
better choice.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to