Thanks Ceki! Two of our projects use NDC so I'll probably leave them with log4j but I might switch the j.u.l calls to SLF4J. I see that j.u.l does support parameterized messages but they don't use varargs so you have to explicitly create an extra Object[] and it requires you to pass the level.
On Tue, Feb 23, 2010 at 11:16 AM, Ceki Gülcü <[email protected]> wrote: > 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] > > -- James A. N. Stauffer http://www.geocities.com/stauffer_james/ Are you good? Take the test at http://www.livingwaters.com/good/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
