Free has the issue in Kotlin that interpreting mul...

# arrow

[raulraja]

Free has the issue in Kotlin that interpreting multiple algebras is not fast as the number grows, we fixed that for Scala in Freestyle but Free + Coproduct doesn't make a lot of sense in Kotlin until we have true union types

[Jörg Winter]

@raulraja
Hi Raul, I guess you refer to a general performance issue. Could you please
• explain a bit more, under which circumstances the performance will degrade ? (if I have, say, only 2 interpreters of one algebra, will it be Ok ?)
• give some insight into the status of 'true union types' in arrow-kt ? (are you working on it.. in meta ?)

[raulraja]

It degrades because nesting algebras in a Coproduct inL inR creates a linked list like structure

[raulraja]

as the nuber of algebras increases dispatching op has higher cost given the coproduct tree needs to be recursed

[raulraja]

the solution is to replace pattermatching for a table switch optimization

[raulraja]

that is give each algebra an index and match on int and cast the types if you want it fast

[raulraja]

Here is the proof

[raulraja]

http://frees.io/docs/optimizations/

[raulraja]

the charts there show the Freestyle coproduct with indexed algebras which has linear performance over the cats coproduct that exponentially gets slow as the nuber of algebras in your program increases

[Jörg Winter]

thx, impressive documentation on frees.io !
So will arrow-kt have true union types at some point ?

[raulraja]

Yes Union types and others are coming to Arrow. I’m gonna show it here next week https://twitter.com/ChicagoKotlin/status/1262352235360473090

[raulraja]

and more in Kotliners and other confs across the year in different unrelated talks about arrow features