On Wed, 23 Feb 2022 22:33:42 GMT, liach <d...@openjdk.java.net> wrote:

> Replaces simple `for (Map.Entry<K, V> entry : map.entrySet())` with 
> `map.forEach((k, v) ->)` calls. This change is better for thread-safety and 
> reduces allocation for some map implementations.
> 
> A more in-depth description of benefits is available at 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086201.html
>  and at the JBS issue itself.
> 
> A [jmh 
> comparison](https://jmh.morethan.io/?sources=https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/base-results.json,https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/head-results.json)
>  on the performance of the existing `HashMapBench` shows that the performance 
> of `putAll` for `HashMap` has not significantly changed.

In a short summary, on mailing list, stuart says this doesn't benefit 
concurrent maps; Remi proposed to deprecate the synchronized collections for 
the peculiarities of iteration; kevin said that this change improves code 
clarity.

Hence, I still believe changing to foreach calls in putAll can potentially 
benefit adding from maps that have expensive iterators and entry wrappers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7601

Reply via email to