Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Jan Burse Newsgroups: comp.lang.java.programmer Subject: Re: java8 up to 6x slower than java7 Date: Sun, 16 Feb 2014 14:38:34 +0100 Organization: albasani.net Lines: 51 Message-ID: References: <29a51a94-8f9a-41b1-980f-e8c13e2d11a2@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 8ii9gfZbJf/W8O19bMaAjqPLerYkNDmJpxq1D0fbuFjrc/+Xls9fD6U/MvmTgiHZHD6KOpjton+H0qkmAfAwyg== NNTP-Posting-Date: Sun, 16 Feb 2014 13:38:41 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="jV5vT9apNw1e0AGJzRfr2JRqPsEQi03U2K8wJ5hP6u2FiIaFEetWI6SCRYL6ng0G9tVV4YP318/3FvMWXcova8gw+RfTHXsEzVTIdW5zfEXI5O06XHPv4IxrwxeqwimI"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 In-Reply-To: Cancel-Lock: sha1:mgqk8aSRKgcfMlWOzIt/jtRs8Dw= Xref: csiph.com comp.lang.java.programmer:27525 Robert Klemme schrieb: > Also, the article does not mention that the fill factor limits the > average length of the chain used for linear probing. Yes, that is also my idea. I guess the problem is bound to bad hashing in the objects that are used as keys, or hashing that remains konstant even when the fill factor changes. I wonder why the web server or any of the business cases that need that improvement do not implement a combination uf HashMap and TreeMap by themselfs, so as to leave the HashMap a more primitive construct. The source code of the new HashMap is found in the early access distribution of JDK 8. It seems that they use a constant threshold: static final int MIN_TREEIFY_CAPACITY = 64; And then there is a lot of copying and creating new objects going on: final void treeify(Node[] tab) { And the tree seems to be sorted first by the hash and by compareTo(). Whereby they use reflection to figure out whether one of the objects implements the generic interface. I guess the above can lead to performance degradation, especially in border cases, for example when one unitentionally runs into the treeification but then doesn't make much use of it. Maybe for non border cases, the new HashMap is ok, probably a bigger memory foot print. I made some application tests over the last days. 1 use case is faster, and 2 use cases are slower. For the slower use cases I am planing using my custom HashMap. The custom HashMap has some further advantages besides sparing the iterator, I also don't do mod counting. One trick to develop a custom HashMap is to use the JDK source code, and create a stripped down variant. Not sure whether copyright allows this really. So I didn't mention that here. Bye