Hey does anyone know if the compiler can optimize ...
# compiler
e
Hey does anyone know if the compiler can optimize away things like this: if (x in (firstContainer + secondContainer)) to avoid creating a new container?
d
I don't think the compiler can trust that
+
operator tbh. Depends on the type but I doubt it's been optimised away.
r
If the two containers were guaranteed immutable it could, but most kotlin collection types are just read only interfaces over mutable classes
e
Ah, that's a good point, shame.
j
if(x in container1||x in container2 )
is not a bad hedge. creating a tiny array of two containers and testing them by size first is reasonably elligable for EA without additional memory speculation cost
having tmp vars to store bigger/smaller container is possibly a smaller and more optimizable target and certainly won't stress gc
y
The compiler does lack in some places where it comes to optimizations. I don't wanna keep writing an essay each time I bring this up, but conceptually if the compiler could guarantee that under the hood adding those 2 collections specifically wrote to a new array of all those items, then possibly it could optimize that away. The issue here is transparency, which is hard-ish to guarantee I guess (because the JVM sort of relies on not knowing method implementations). I believe that
plus
for collections is inline, and so probably what's missing is to optimize the case where a collection is created out of multiple others only for a single check. However, what would be even better, instead of relying on little optimizations in the compiler, is if we took a page out of fp land and went with a lazy approach here. If those 2 containers were added together into a sequence in a lazy fashion, then that sequence would implement its methods to also reflect that. For example, for a special
PlusSequence
, it can implement its
contains
method to check the 2 containers inside of it. The only issue with this solution is the creation of the extra Sequence object, which isn't ideal because it kind of takes away the value of the optimization. However, with Valhala value classes, or KT-44530, this new sequence can just be inlined and would never have to exist as an object in memory. I had been developing a compiler plugin that can acomplish that, and I'm gonna resume development soon.