can you please rewrite it without using fx, see if there’s any improvement?

# arrow-contributors

[pakoito]

can you please rewrite it without using fx, see if there’s any improvement?

[PhBastiani]

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

[pakoito]

wink

[pakoito]

fx relies on reflection, it's specially slow on Android

[Jannis]

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^^

[Jannis]

@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.

[Jannis]

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

[Jannis]

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^^

[PhBastiani]

@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.

[Jannis]

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.

[Jannis]

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)