LoggerContext logger cache
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
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
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
participants (2)
-
Ceki Gulcu -
Ralph Goers