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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
