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

[Сергей Цыпанов]

On Thu, 14 Jan 2021 10:18:23 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> ...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.

I cannot modify JIRA ticket without account there, so let's keep it as is

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

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