[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    Re: Performance of not logging in Log4J vs. JDK 1.4 Logging
From:       Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki () qos ! ch>
Date:       2003-10-29 18:58:24
[Download RAW message or body]

At 10:42 AM 10/29/2003 -0800, David McVicar wrote:
>Toby, Yoav,
>
>Thanks for the responses.
>
>Yoav:
>
>Thanks for explaining the Hierarchy.setThreshold()
>method - if I was to change the config to effectively
>set this would I get a performance gain?  I would
>prefer not to have to call this method in Java and
>would like to do this via configuration.

You can set the hierarchy-wide threshold as follows:

log4j.threshold=someLevel

where someLevel can be any of ALL, DEBUG, INFO, ..., OFF.

Set to it to INFO and see the impact on performance.
(My guess would be a 3 to 4 fold improvement.)

>Toby:
>
>You are right, I shouldn't have been mixing properties
>files with xml files, it wasn't a fair comparison.  I
>have changed to using both properties files.
>
>I have also updated the code to explicitly display the
>time taken to execute just the Log4J and JDK 1.4 code
>using direct calls to Date().getTime().  Strictly
>speaking this was not necessary as I was reusing the
>JUnitPerf classes from Mike Clark (www.clarkware.com).
>  JUnitPerf is an Open Source add on to JUnit that
>allows you to measure the performance of JUnit tests,
>as I was initialising the Logger in the constructor of
>the JUnit TestCase class and not in the method that
>JUnitPerf was timing the differences between
>properties and xml config files shouldn't have made a
>difference.  Anyway for clarity its changed now and
>you can run each test directly.
>
>I also take your point that "benchmarking by
>iteration" is not the best way to measure the overall
>performance of Log4J however the specific test that I
>am performing here is to understand the difference in
>duration between leaving JDK 1.4 and Log4J logging
>code in place and configuring it not to log any
>messages.  As I said before the only reason that I am
>iterating 10 million times is to get a significantly
>measurable result as to perform the division and
>calculate the cost of leaving a single logging
>statement that is configured not to log.
>
>Unfortunately the changes didn't make any difference
>to the results, this time for 10 million iterations it
>was:
>
>JDK 1.4 : 441 ms
>Log4J   : 901 ms
>
>I think that this illustrates that for a comparable
>test where the general configuration of both JDK 1.4
>and Log4J is to log messages BUT a specific class has
>been configured NOT to log that JDK 1.4 is faster.  If
>Log4J was enhanced to check earlier comparable
>performance results could be acheived.

Two short comments:

1) Spending under 1 second for 10 million trials is not bad. Your
tests show that in a single threaded application calling disabled log
statements is hardly an issue.

Btw, I am not saying this as a sore loser because log4j seems to be
slower on this test. With the hierarchy-wide threshold the figures
should be in log4j's favor.

2) The really interesting question is how both API perform on a loaded
server...


-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]