On Mon, 21 Feb 2022 06:33:05 GMT, liach wrote:
> Unfortunately I don't think there is any for now.
@liach
Yes. that is why I ask if there be evidence to show `(int) ((1 + m.size()) *
1.1)` be an optimization, but not otherwise.
(IMO it is otherwise.)
-
PR:
On Sun, 20 Feb 2022 20:30:29 GMT, XenoAmess wrote:
>>> You should run benchmarks to see how bad the lookup performance degrades
>>> after you saves memory used by the hash table.
>>
>> OK, would find some time for it.
>
>> > You should run benchmarks to see how bad the lookup performance
On Sun, 20 Feb 2022 20:03:07 GMT, XenoAmess wrote:
> > You should run benchmarks to see how bad the lookup performance degrades
> > after you saves memory used by the hash table.
>
> OK, would find some time for it.
@liach which jmh test should I run by the way?
Or is there some commandline
On Sun, 20 Feb 2022 20:02:09 GMT, XenoAmess wrote:
> You should run benchmarks to see how bad the lookup performance degrades
> after you saves memory used by the hash table.
OK, would find some time for it.
-
PR: https://git.openjdk.java.net/jdk/pull/7431
On Sun, 20 Feb 2022 19:11:26 GMT, liach wrote:
> > I don't thik it reasonable. or is there eveidence it be?
>
> If this map is too dense, there may be a lot of hash collisions, and the
> lookup performance would decrease because this hashmap is linear probe than
> red-black tree buckets like
On Sun, 20 Feb 2022 19:41:22 GMT, XenoAmess wrote:
>> In fact, if we do worry about the performance of adding from maps, calling
>> `map.forEach(this::put);` would be a better alternative both in concurrency
>> (as the concurrent map itself takes charage) and object allocation-wise (no
>>
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with one additional commit
since the last revision:
refine IdentityHashMap
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7431/files
- new:
On Sun, 20 Feb 2022 19:19:16 GMT, liach wrote:
>> Imo you should just remove the `if (expectedSize == 0)` check than using
>> this somewhat ugly trick to avoid calling `size()` twice (the second call is
>> only used for this relatively useless fast-path, especially for the
>> concurrent
On Sun, 20 Feb 2022 19:08:39 GMT, liach wrote:
>>> @liach implementations `size()` seems O1, and returns a single int number
>>> field, but it actually defers in some Map implementations.
>>
>> @liach for example, in ConcurrentSkipListMap and ConcurrentHashMap, `size()`
>> function is far
On Sun, 20 Feb 2022 18:44:09 GMT, XenoAmess wrote:
>> src/java.base/share/classes/java/util/IdentityHashMap.java line 281:
>>
>>> 279: * @throws NullPointerException if the specified map is null
>>> 280: */
>>> 281: private IdentityHashMap(Map map, int
>>> expectedSize) {
>>
>>
On Sun, 20 Feb 2022 18:08:24 GMT, XenoAmess wrote:
> I don't thik it reasonable. or is there eveidence it be?
If this map is too dense, there may be a lot of hash collisions, and the lookup
performance would decrease because this hashmap is linear probe than red-black
tree buckets like the
On Sun, 20 Feb 2022 18:20:27 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - refine test
>> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call
>> map.size() twice but once.
>>
On Sun, 20 Feb 2022 18:38:35 GMT, XenoAmess wrote:
>> src/java.base/share/classes/java/util/IdentityHashMap.java line 281:
>>
>>> 279: * @throws NullPointerException if the specified map is null
>>> 280: */
>>> 281: private IdentityHashMap(Map map, int
>>> expectedSize) {
>>
>>
On Sun, 20 Feb 2022 18:20:27 GMT, liach wrote:
>> XenoAmess has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - refine test
>> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call
>> map.size() twice but once.
>>
On Sun, 20 Feb 2022 18:08:37 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - refine test
> - 1. optimize IdentityHashMap that
On Sun, 20 Feb 2022 18:03:07 GMT, XenoAmess wrote:
>> XenoAmess has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - refine test
>> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call
>> map.size() twice but once.
On Sun, 20 Feb 2022 18:04:50 GMT, XenoAmess wrote:
>> 8281631: HashMap copy constructor and putAll can over-allocate table
>
> XenoAmess has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - refine test
> - 1. optimize IdentityHashMap that
> 8281631: HashMap copy constructor and putAll can over-allocate table
XenoAmess has updated the pull request incrementally with three additional
commits since the last revision:
- refine test
- 1. optimize IdentityHashMap that when calling ::new(Map), do not call
map.size() twice but once.
On Sun, 20 Feb 2022 16:12:08 GMT, Andrew Haley
wrote:
> I don't think this is terribly important, but I don't like to see attempts at
> hand optimization in the standard library.
OK, we've decided use that Math.ceil() solution.
-
PR: https://git.openjdk.java.net/jdk/pull/7431
On 2/11/22 19:25, XenoAmess wrote:
On Fri, 11 Feb 2022 18:24:49 GMT, Andrew Haley wrote:
Just multiply by 0.75.
On a modern design, floating-point multiply is 4 clocks latency, 4 ops/clock
throughput. FP max is 2 clocks latency, conversions int-float and vice versa 3
clocks latency, 4
20 matches
Mail list logo
