logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35052] - Problem with String.intern() in CategoryKey
Date Fri, 22 Jul 2005 05:15:49 GMT
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


carnold@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From carnold@apache.org  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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message