Could anyone please provide some feedback here: I ...

# getting-started

[Chris Fillmore]

Could anyone please provide some feedback here: I am considering using the Kotlin Immutable Collections library in my Android project (https://github.com/Kotlin/kotlinx.collections.immutable). My use case is: I have a model of some data, and the data can have a variety of different attributes depending on some external-vendor-specific logic. I had previously modelled this with composition and delegation, but this leads to a lot of boilerplate and I’m considering writing a “Traits” utility which would allow different instances to have different traits in a collection. The number of traits currently is low, but I’m trying to be conscious of having to look up traits in a collection on every UI recomposition. I wonder if immutable collections would have a performance benefit here (even if small).

[Casey Brooks]

It's probably not worth bring that library in unless you actually observe a significant drop in performance. Compose is very good as avoiding unnecessary work, those collections are going to be more difficult to use than the normal collections, and don't quote me on this but I believe those Immutable collections are generally less-performant than the stdlib collections, currently. They're immutable not for performance reasons, but to provide deep immutability guarantees that the stdlib Collections interfaces do not.

That said, if you're doing frequent lookups of the trait and concerned about potentially-expensive lookups, maybe a Map is a better choice than List for holding onto them. Make each Trait identified by some Key in the Map rather than searching a List for the actual type, with generics to enforce type-safety of Keys to Trait values.

[Chris Fillmore]

Thanks for responding, in fact I just switched the implementation to use a Map. I’ll see how it goes