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