Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Concurrency question? Date: Sun, 08 Feb 2015 19:33:21 +0100 Lines: 35 Message-ID: References: <54ce6897$0$289$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net aBpaO9PiWY2xt9nUf5+k9wPPwV3PbRFLQQ8OmqrDmDx74gc+k= Cancel-Lock: sha1:eZwasdvL5BlO3du7UVD7C9Ro8Z4= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:31087 On 07.02.2015 07:29, Kevin McMurtrie wrote: > In article <54ce6897$0$289$14726298@news.sunsite.dk>, > Arne Vajh=C3=B8j wrote: > >> On 2/1/2015 1:59 AM, Kevin McMurtrie wrote: >>> I don't recommend ConcurrentHashMap EVER unless you need atomic >>> conditional updates. The implementation is expensive and it's still = not >>> entirely lock free. You need a lot of concurrency from a lot CPU cor= es >>> before you'll see it outperform the old Hashtable class. >> >> That is not my experience. CHM seems to be as fast or faster than Ht >> in most cases I have seen. > size(), isEmpty(), and toArray() are slower and must allocate temporary= > objects. get() and put() can be comparable in speed to HashMap, minus > some overhead for the internal sharding used to reduce lock scope. But then it is entirely dependent on the use case whether one or the=20 other is faster (well, no surprises here). That is quite a different=20 statement than the one you made above which gave the impression that CHM = is only better in some arcane special cases with "a lot of concurrency". Kind regards robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/