[logback-dev] LoggerContext logger cache

[Ceki Gulcu]

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