Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #27531
| 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> |
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
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