Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #27531

Re: java8 up to 6x slower than java7

From Jan Burse <janburse@fastmail.fm>
Newsgroups comp.lang.java.programmer
Subject Re: java8 up to 6x slower than java7
Date 2014-02-16 20:27 +0100
Organization albasani.net
Message-ID <ldr3ep$m2v$1@news.albasani.net> (permalink)
References (2 earlier) <ldnkf1$pp0$1@news.albasani.net> <bmbo69F4b27U1@mid.individual.net> <ldqf11$adv$1@news.albasani.net> <ldqf9a$adv$2@news.albasani.net> <bmbu5tF5ju8U1@mid.individual.net>

Show all headers | View raw


Hi,

Robert Klemme schrieb:
> 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.

You have this effect and can control this effect by an appropriate
lower water mark choice. Without putting some special compaction
points into your code. Overhead is only a compare instruction
besides the compaction itself.

It should be noted that you are true, that the compaction is not
necessary. It does even make the hashing less good, since you
have fewer bins. Normally a hash map that grows and grows, will
nevertheless have smaller bin lengths when elements are
removed again.

Main reason I opted for automatic compaction of my hash maps was
that my application has miriads of hash maps. Well not miriads,
but a lot of hash maps. They are used for some just in time indexing,
and are even recursively built, i.e. hash values that are again hash 
maps and so.

So the requirement was really to have very light weighted hash
maps for this data structure. Even if there is a small time overhead.
Problem was that application crashed without compaction, since
memory consumption was too high.

Bye


Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

java8 up to 6x slower than java7 Dennis Haupt <d.haupt82@gmail.com> - 2014-02-15 03:00 -0800
  Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-15 12:26 +0100
    Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-15 12:28 +0100
    Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-15 12:52 +0100
      Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-16 13:10 +0100
        Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 14:38 +0100
          Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 14:43 +0100
            Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-16 14:53 +0100
              Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 20:27 +0100
                Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-02-16 20:36 +0100
                Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-17 18:55 +0100
                Re: java8 up to 6x slower than java7 Wanja Gayk <brixomatic@yahoo.com> - 2014-03-02 20:52 +0100
                Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-03-03 11:53 +0100
                Re: java8 up to 6x slower than java7 Joerg Meier <joergmmeier@arcor.de> - 2014-03-03 17:16 +0100
                Re: java8 up to 6x slower than java7 Jan Burse <janburse@fastmail.fm> - 2014-03-03 19:53 +0100
                Re: java8 up to 6x slower than java7 Lew <lewbloch@gmail.com> - 2014-03-03 13:44 -0800
      Re: java8 up to 6x slower than java7 Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-16 11:24 -0800
  Re: java8 up to 6x slower than java7 Robert Klemme <shortcutter@googlemail.com> - 2014-02-15 12:55 +0100
  Re: java8 up to 6x slower than java7 "Qu0ll" <Qu0llSixFour@gmail.com> - 2014-02-15 23:42 +1100
  Re: java8 up to 6x slower than java7 Roedy Green <see_website@mindprod.com.invalid> - 2014-02-16 00:25 -0800

csiph-web