logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James A. N. Stauffer" <stauffer.ja...@gmail.com>
Subject Re: Measuring logging performance impact (including string concatenation)
Date Tue, 23 Feb 2010 18:14:39 GMT
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

On Tue, Feb 23, 2010 at 11:16 AM, Ceki Gülcü <ceki@qos.ch> 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: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org


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: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message