Using nanoTime(), using HashTable instead of HashMap, allowing JIT compiler to
warm up, and pre-instantiating the keys and values to be inserted into the map,
I get:
SINGLE THREADED TEST
====================
Hashtable Build time (2000): 376
Hashtable Search time (2000): 3778
ConcurrentMap Build time (2000): 824
ConcurrentMap Search time (2000): 1945
MULTI THREADED TEST
===================
Hashtable-15 Build time (2000): 423
Search time, average=1041, max=3335
ConcurrentMap-15 Build time (2000): 765
Search time, average=225, max=628
I find it quite astonishing that search time for ConcurrentMap is
*faster* than with Hashtable (in the single thread case). In the
multi-threaded case (15 threads) the difference in performance is
remarkable but not surprising.
Ceki Gulcu wrote:
Good idea. Note that since the logger cache is such a core component,
1) the change would need to be heavily tested 2) some performance
figures comparing the old and new would be valuable.
Come to think of it, since the logger cache is used while creating new
loggers or retrieving existing loggers, only code that routinely
retrieves loggers would be impacted. Is that the case in your
environment?
The first few figures in [1] look very suspicious.
SINGLE THREADED TEST
====================
HashMap Build time (1000): 15
HashMap Search time (1000): 0
HashMap Build time (10000): 32
HashMap Search time (10000): 15
ConcurrentMap Build time (1000): 0
ConcurrentMap Search time (1000): 0
ConcurrentMap Build time (10000): 15
ConcurrentMap Search time (10000): 0
I have not looked at the details but, unless Doug's impl of the
hashmap is better than Sun's in the single threaded case, which I
doubt, Steven Haines' number are probably a little inaccurate as he
uses System.currentMillis instead of System.nanos in his code. He also
spends time creating the objects to insert into the map which muddies
his comparisons. Of course, the multi-threaded case is a whole
different ball game.
[1] http://www.informit.com/guides/content.aspx?g=java&seqNum=246
Ralph Goers wrote:
LoggerContext uses a Hashtable for the logger cache. A Google on
"hashtable ConcurrentHashMap performance" shows that ConcurrentHashMap
should perform much better under load. I looked at doing this in my
fork and can't see any reason why it would be a problem. I did see a
post where ConcurrentHashMap is quite a bit larger than Hashtable, but
since there is only going to be one of these that shouldn't be a problem.
http://www.informit.com/guides/content.aspx?g=java&seqNum=246
Ralph
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
