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

[Peter Levart]

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

>> @forax, @plevart could I ask for review once again?
>
> 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....

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

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