DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35052>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35052 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From [EMAIL PROTECTED] 2005-07-22 07:15 ------- I've committed a performance test for Logger.getLogger on the CVS HEAD. To run: cd tests ant build ' once to build unit tests ant -f performance.xml getLogger I've run the tests with the current implementation and two alternative implementations. The test, by default, calls getLogger() for 1000 different logger names of typical length. The first pass is much more expensive than the subsequent passes since new instances of Logger will be created for each name. Subsequent passes simply retrieve the previously created loggers. The baseline results were ~3200 ms for the pass 0 and 123 ms on average for passes 1-9. The first modification was: diff -r1.5 CategoryKey.java 29c29 < this.name = name.intern(); --- > this.name = name; 43c43 < return name == ((CategoryKey) rArg).name; --- > return name.equals(((CategoryKey) rArg).name); After this change: pass 0: ~1900 ms, 77 ms average, 38 ms min for passes 1- 9 This indicates that (at least on this JVM), that initial call to String.intern adds substantial time to the creation of a new Logger and use of == is slower than name.equals() surprisingly. The second change was to eliminate the use of CategoryKey altogether: RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/Hierarchy.java,v retrieving revision 1.62 diff -r1.62 Hierarchy.java 79c79 < Hashtable ht; --- > private Hashtable ht; 227c227 < Object o = ht.get(new CategoryKey(name)); --- > Object o = ht.get(name); 447c447 < CategoryKey key = new CategoryKey(name); --- > String key = name; 726c726 < CategoryKey key = new CategoryKey(substr); // simple constructor --- > String key = substr; // simple constructor The results for this mod were, on average, slightly better than the previous iteration at ~1800 ms and 61 ms average, 20 ms min for passes 1-9. These results were from: java version "1.4.2_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-215) Java HotSpot(TM) Client VM (build 1.4.2-50, mixed mode) on Mac OS/X. Running a JRE 1.2 on Win98 SE: Stock: Pass 0: 1000 ms, pass 1-9: avg 66, min 0 Mod 1: Pass 0: 550 ms, Pass 1-9: avg 48, min 0 Mod 2: Pass 0: 550 ms, pass 1-9: avg 67, min 0 Running JRE 1.5.0 on Win XP Stock: Pass 0: 390 ms, pass 1-9: avg 12 ms, min 0 Mod 1: Pass 0: 203 ms, pass 1-9: avg 5 ms, min 0 Mod 2: Pass 0: 172 ms, pass 1-9: avg 3 ms, min 0 My take is that anything 1.2 or later would likely not benefit from the String.intern "optimization". Unless we can find a platform where it does offer a compelling advantage, my current take would be to do Mod 1 on the log4j 1.2 branch and mark CategoryKey deprecated (it is already only visible within the package) and do Mod 2 on the CVS HEAD. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
