[logback-dev] LoggerContext logger cache

[Ceki Gulcu]

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