Hello James, There is no perfect way to measure the overhead of parameter constructions, but 200 nanosecond is a reasonable lower bound. So, if you call a disabled logger 1'000'000 times you will see an overhead of at least 200 milliseconds. Nothing to call home about. However, the toString() methods of certain objects can be very costly so the impact of parameter construction can be much higher than 200 nanos.
BTW, SLF4J handles this use case very nicely. Note that slf4-api.jar is 23K in size and slf4j-jdk14.jar (which logs to java.util.logging) is only 8K. If you were using the SLF4J API, you could instruct SLF4J to delegate to java.util.logging via slf4j-jdk14.jar, solving the overhead problem at the cost of additional 31K to download during applet start up. Moreover, if you were using SLF4J throughout your application, the rest of your application could share code with the applet as both the application and the applet would be using the same logging API. Your application of course could continue to delegate logging to log4j as you do currently. HTH, -- Ceki http://logback.qos.ch: The reliable, generic, fast and flexible logging framework. On 23/02/2010 5:53 PM, James A. N. Stauffer wrote:
Our applications have extensive use of logging (most commons-logging over log4j, and j.u.l). We use j.u.l for code that runs in an applet so we don't incur the cost of an extra jar download. Since we don't have access to message formats, we incur the cost the log message string concatenation even when the level is turned off. We could wrap every log call in a level check but that makes the code more messy. Is there a good way to measure the performance impact (i.e. % of CPU time) used for logging statements (include the string concatenation for the log message)?
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
