https://issues.apache.org/bugzilla/show_bug.cgi?id=52206

--- Comment #2 from Alexis Giotis <alex.gio...@gmail.com> 2011-11-21 21:14:00 
UTC ---
Hi Vincent, 

I guess you are referring to the removed lines in PropertyMaker.java. 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(Category.java:442)
    at org.apache.log4j.Category.isEnabledFor(Category.java:751)
    at
org.apache.commons.logging.impl.Log4JLogger.isTraceEnabled(Log4JLogger.java:333)
    at org.apache.fop.fo.properties.PropertyMaker.make(PropertyMaker.java:380)
....
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
http://logback.qos.ch/manual/architecture.html

"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: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to