https://kotlinlang.org logo
#arrow-contributors
Title
# arrow-contributors
p

pakoito

03/02/2020, 10:55 AM
can you please rewrite it without using fx, see if there’s any improvement?
p

PhBastiani

03/02/2020, 1:46 PM
arrow.benchmarks.TrampolineBench.evalFx 8146,327 ms/op arrow.benchmarks.TrampolineBench.eval 523,954 ms/op arrow.benchmarks.TrampolineBench.trampolineFx 9828,946 ms/op arrow.benchmarks.TrampolineBench.trampoline 1580,619 ms/op cats.benchmarks.TrampolineBench.eval 682,068 ms/op cats.benchmarks.TrampolineBench.stdlib 618,839 ms/op cats.benchmarks.TrampolineBench.trampoline 1639,737 ms/op Big change with a flatmaped methods ! Arrow even seems to be better than Scala DO arrow
p

pakoito

03/02/2020, 2:28 PM
wink
fx
relies on reflection, it's specially slow on Android
j

Jannis

03/02/2020, 3:34 PM
Time to add
FreeT
to arrow and benchmark it against coroutines and
IO
.
FreeT
together with
f ~ EitherPartialOf<Throwable>
is equal to kotlin coroutines. Wonder where that would lead^^ Likely worse atm, but with actual newtypes this might even be able to compete. Although this would likely end up being a benchmark of the interpreter/runloop/scheduler instead of actual programs as soon as the programs grow in size. Definitely something that I will test some day^^
😍 2
@PhBastiani btw we have two other ways of making something stacksafe in arrow that might be worth testing:
AndThen
and
IO
. (Not sure if
AndThen
works in that context but it should). Would be interesting to see how those compare.
Also one of the ank examples for recursion schemes has a fibonacci implementation. It uses a histomorphism over
Cofree
and
Option
. It is not a good benchmark target though because a histomorphism automatically caches prior results with a shapeshifting cache (
Cofree
+
Option
provide a linked list cache,
Cofree
+
ListK
would provide a tree and so on. Basically every functor that you combine with
Cofree
provides a different sort of cache). If you want to see how that works, here is the example: https://github.com/arrow-kt/arrow-incubator/blob/master/arrow-recursion-data/src/main/kotlin/arrow/recursion/typeclasses/Recursive.kt#L191
Only the
histoM
version is stacksafe (by using
Eval
, or any other stacksafe
M
). But because this does so little work it takes a while to overflow it. Also the stacksafe variant provides some stupid results as soon as it overflows long numbers, but it's really fast^^
p

PhBastiani

03/03/2020, 10:09 AM
@Jannis for pointing
histoM
sample out to me. About `AndThen`: I don't know... because of the lack of a deferred method. For sure we could segment or memoize some parts of the recursive algo.
j

Jannis

03/03/2020, 10:19 AM
AndThen
isn't really that important. I think it is possible to run it, but you'd have to vary the implementation a bit.
IO
would be interesting to see though. The histo version is probably a lot faster than anything else, but that is because of the implementation and not the datatype.
Oh and for fibonacci numbers the memoization of eval doesn't matter unless you run the result eval multiple times. The eval's created in the middle are not shared and thus don't matter. Only the full end result is memoized. So as long as your benchmark does
evalFib(n).value()
it will not memoize a thing. (unless the jvm does it's magic, but I don't think that is the case)
2 Views