Releases: Kotlin/kotlinx.collections.immutable
Releases · Kotlin/kotlinx.collections.immutable
v0.2
This release introduces two notable changes.
Split immutable and persistent interfaces
- Immutable collections specify by their contract the real immutability of their implementors
ImmutableCollectionextends read-onlyCollectionImmutableListextends read-onlyListandImmutableCollection, and overridessubListmethod that returnsImmutableListImmutableSetextends read-onlySetandImmutableCollectionImmutableMapextends read-onlyMap, and overrideskeys,valuesandentriesproperties types withImmutableSet,ImmutableCollectionandImmutableSetrespectively
- Persistent collections extend immutable collections and provide modification operations that return new instances with the modification applied
PersistentCollectionextendsImmutableCollection, and provides modification operations and builderPersistentListextendsImmutableListandPersistentCollection, and provides modification operationsPersistentSetextendsImmutableSetandPersistentCollection, and provides modification operationsPersistentMapextendsImmutableMap, and provides modification operations and builder
plus,minusandmutateextension functions are available only for persistent collections- Deprecate
immutableXOf()top-level functions and introducepersistentXOf() toImmutableX()extension functions returnImmutableX- Introduce
toPersistentX()extension functions that returnPersistentX - Document public API
Replace PCollections-based prototypes with custom performant implementations
PersistentListimplementation is backed by a bit-mapped trie with branching factor of 32add(element: E)andremoveAt(size - 1)operations take O(1) time, down from O(log2n) 📉getandsetoperations take O(log32n), down from O(log2n) (though the same asymptotic) 📉- Iteration has the same time complexity of O(n), but much faster in practice due to the better reference locality 📉
- Unordered
PersistentSetimplementation is backed by a hash-array mapped trie (a.k.a. HAMT) with up to 32 children or elements in a nodecontains,addandremoveoperations take O(log32n) time, down from O(log2n) 📉- Iteration has the same time complexity of O(n), but much faster in practice due to the better reference locality 📉
- Unordered
PersistentMapimplementation is backed by a compressed hash-array mapped prefix-tree (a.k.a. CHAMP) with up to 32 children or entries in a nodecontains,get,putandremoveoperations take O(log32n) time, down from O(log2n) 📉- Iteration has the same time complexity of O(n), but much faster in practice due to the better reference locality 📉
- Ordered
PersistentSetimplementation is backed by the unorderedPersistentMapwhich maps elements in this set to next and previous elements in insertion ordercontains,getandputoperations take O(log32n) time, down from O(log2n) 📉removeoperation takes O(log32n) time, down from O(n) 📉- Iteration takes O(n log32n) time, up from O(n) 📈
- Ordered
PersistentMapimplementation is backed by the unorderedPersistentMapwhich maps keys in this map to values, next and previous keys in insertion ordercontains,getandputoperations take O(log32n) time, down from O(log2n) 📉removeoperation takes O(log32n) time, down from O(n) 📉- Iteration takes O(n log32n) time, up from O(n) 📈
- Builders are backed by the same backing storage as the corresponding persistent collections, but apply modifications in-place if the node has already been copied
- Time complexities of all operations are the same as of the corresponding persistent collections. However, avoiding memory allocations leads to significant performance improvement 📉