Benchmark against Most.js about flyd HOT 3 OPEN

@Mapiac aside perf questions, flyd and most.js are slightly different in architecture. most.js is more of an Observable (instantiates new «pipe» for every client, with optional ability to «multiplex»), flyd is an event graph («multiplexed» by default, like an event emitter but with atomicity).

I'm currently working on my own event graph, highly inspired by flyd (here). I'm targeting flyd in perf tests. However, I've never perf against most.js since it's Observable.

Last time I looked into most.js, it's main gimmick was to fusion multiple elements in pipe into one step (which is possible in Observable), function compose + jit might do great perf improvement.

from flyd.

I definitely agree with your assessment @StreetStrider.

Good luck with Fluh 👍

from flyd.

@Mapiac as time goes on, I was inspired to perf against Observable libraries. I was focusing on my library, fluh, and not flyd itself, but since I kinda beat flyd, this still may be informative for you and the others. (And, I think flyd can beat me if it would cache graph, like fluh and because my lib is very similar to flyd in general).

So, my results is that most.js is best in deep-linear scenario (100 consecutive stream items or event graph nodes) and in shortcut scenario (filtering out elements in the middle of the chain). This is expectable because of the fusion. flyd is also good in shortcut, my library is the second. Observable libraries are not good in triangle scenario, event graph libraries are OK in that, my library is the best. RxJS is kinda slow in general. most.js is really fast, but it consumes a lot of memory in comparison to other libraries. I still don't know how much, but I was forced to high --max-old-space-size because of the most.js. Either, it would crash node where any other library pass smoothly.

Eventually I will measure memory consumption, that would be interesting. I was looking for leaks in my code and it seemes that memory consumption is low and stable. But event graph is still an overhead and it is irreducible overhead in comparison to plain code.

I think in future it would be nice to have a language where FRP is a core feature and it is managed by the smart compiler which is able to reduce it to plain code.

from flyd.