Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: java8 up to 6x slower than java7 Date: Sun, 16 Feb 2014 14:53:00 +0100 Lines: 31 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: individual.net SsgWTnCi2sElsh0hA2Oa7wsOR7pl5RO7kUb4DjWGyBNSeK/1A= Cancel-Lock: sha1:D0hjnpo1K8dgjhkSZ9Pk8dHGsFI= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:27527 On 16.02.2014 14:43, Jan Burse wrote: > Jan Burse schrieb: >> 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. > > Last but not least, one feature I am constantly missing > from HashMap, is that it should grow back in size. > HashMap is only growing and growing, and never > automatically shrinks. Usually there is good reason to not do this: if a long lived collection reaches a particular size at some point in time chances are that it will do so in the future again. Shrinking will cause allocation overhead and - at a later point - another allocation for the larger size which has higher risk of causing slow GC because of memory fragmentation. Also, if the long lived collection resizes internally at least for some GC cycles there is a reference from old gen to new gen. For short lived objects additional allocations to save memory are even worse. There it's usually best to just grow. For the long lived case you can still manually shrink by creating a new collection if the nature of your application is such that there temporarily the collection grows huge and afterwards shrinks again. Kind regards robert