RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

Peter Levart plevart at openjdk.java.net
Thu Jan 14 10:21:01 UTC 2021

On Fri, 8 Jan 2021 11:39:17 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi @stsypanov, 
>>> The **behavior** of this convenience method is **identical** to that of c.addAll(Arrays.asList(elements))
>> What about:
>>> The **behaviour** of this convenience method is **similar** to that of c.addAll(Arrays.asList(elements))
>> ...since it is not entirely identical. The outcome is usually identical because collections usually adhere to the specification, but we can not claim the behaviour is identical if the target collection does not adhere.
> ...but we could employ this method to guarantee more than `c.addAll(Arrays.asList(elements))` does. So what about:
>> The behaviour of this convenience method is similar to that of `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))`
> This means that the method guarantees that the passed in `elements` array will not be modified even if given collection `c` is not trusted. Speaking of that, perhaps you could try benchmarking such `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` and see how it compares. The speed-up you observed from `c.addAll(Arrays.asList(elements))` with some collections was probably a result of them calling .toArray() on the argument collection and incorporating the resulting array into their own data structure in a bulk-copying-way. So `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` might have same performance characteristics while guaranteeing same things about argument array. It might be slower when Iterator is employed though because unmodifiableList wrapper wraps Iterator(s) too....

> @plevart done. Should I also rename this PR to e.g. 'Fix performance-related notation in Collections.addAll'?

I think the title of JIRA ticket has to be the same as that of PR (with JIRA bug number prepended) in order to pass all checks needed for integrating. So If you modify both, it would be fine.


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

More information about the core-libs-dev mailing list