https://issues.apache.org/bugzilla/show_bug.cgi?id=52206
--- Comment #2 from Alexis Giotis <[email protected]> 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.
