Retrieval of 100000 elements from the end of a non-modifiable list: 3 Retrieval of 100000 elements from the end of a linked list: 25 Retrieval of 100000 elements from the start of a non-modifiable list: 3

Retrieval of 100000 elements from the start of a mutable list: 22 Retrieval of 100000 elements from the start of a linked list: 28 Insertion of 100000 elements to the end of a mutable list: 16 Insertion of 100000 elements to the end of a non-modifiable list: 9670 Insertion of 100000 elements to the start of a non-modifiable list: 18 Insertion of 100000 elements to the start of a mutable list: 1411 Here are the results (in milliseconds): Insertion of 100000 elements to the start of a linked list: 61 A scan is like a fold but producing a list of all the intermediate results. I have compared operations that are not well suited to linked lists as well as one which is: a scan of the list. I have made a benchmark comparing (immutable persistent) linked lists, Kotlin mutable lists, and Kotlin’s non-modifiable lists. The problem is that people arguing against linked lists (note that I am talking about immutable persistent linked lists and not Java linked lists) generally “forget” this.

Programmers know that they have to make defensive copies when necessary. I have seen many bugs due to the fact that these lists are not persistent. The only question is whether they are useful for some use cases or not.Īrray-based lists are very error-prone too. Whether programmers are able or not to make an educated decision about using linked lists is irrelevant. Thinking that programmers would be worst than I am or even as bad as I am and that it would be a valid reason to remove linked lists would be basing the decision upon cognitive bias. What I meant is that it was insulting for programmers in general, and that insult is not an argument.

Kotlin linkedlist