On the other hand, that complexity is reduced to a constant time for sets. We have to go through each item one by one. Typically, the complexity of checking for the existence of an item in a regular list or array is linear. But how does it know that a specific item is not present in that collection? By calling its contains method. It does that by filtering the first collection to keep only the items that are not in the second collection. It returns a list consisting of elements from the first collection that are not present in the second collection. In many cases, when running some of the Collection operations (such as aforementioned intersect, minus, removeAll or retainAll), Kotlin tried to optimize them by converting their second operands to a Set under the hood. That’s why it might be worth providing a little story behind this issue: Before Kotlin 1.6 ¶ In prior versions, both of those tested variants ( x intersect y and y intersect x) would yield the same results. Moreover, this problem only exists starting with Kotlin 1.6.

Overall, as I dig deeper into the topic (including the source code of the intersect function), I realized that the problem is not the order of the operands itself, but rather the fact that the second operand in the slower variant was not of type Set. What’s more, the bigger the y collection, the greater the time difference between those two variants. average ())Īs you can see, the outcome is quite surprising. Val results = mutableListOf () repeat ( 20 ) print ( results.

Kotlin list to set