These are chat archives for pozadi/kefir

1st
Apr 2017
Roman Pominov
@rpominov
Apr 01 2017 10:04
Hi, @rekotiira . Good question! Kefir runs function eagerly because these functions are supposed to be pure, and if laziness is required it supposed to be provided by streams themselves (a stream doesn't do side effects before one subscribes to it). But Promises do break this reasoning :(. Creating a promise is always effectfull if promise does something useful. I think what flatMapConcat does is correct, but there is a problem in Kefir.fromPromise API, it should also accept a function returning a promise, i.e. both Kefir.fromPromise(promise) and Kefir.fromPromise(() => promise) should work. I actually thought it's done that way already, but turns out it's not.
To clarify Kefir.fromPromise(() => promise) would call provided function lazily only when someone subscribes to the observable.
Sorry for super slow response, btw. Been very busy at work this week.
Vesa Karvonen
@polytypic
Apr 01 2017 13:48
@rpominov What is your stance on optimizing Kefir? I've been reading the Kefir codebase and I believe there are several low hanging fruits for optimization. For example, every observable now includes a couple of extra fields (_logHandlers and _spyHandlers) for debugging. Eliminating those when they are not used would slow down things when debug features are used, but would reduce memory usage when they are not used. Another example is the way remove and add in Dispatcher work: a sequence of n add operations followed by n remove operations perform as O(n^2) (https://accidentallyquadratic.tumblr.com/). That can be improved so that typical patterns, i.e. remove in reverse order of add, run in O(n) time. A third example would be that the implementation currently seems to create lots of copies of event objects unnecessarily. Avoiding unnecessary copying could give a performance boost as avoiding allocations really seems to be one of the keys to improving JS perf. Shall I create PRs for these optimizations?
Roman Pominov
@rpominov
Apr 01 2017 15:10
Hey, @polytypic ! After most.js came out I've gave up on optimizations in Kefir to be really honest. JS vms are so complicated, that you often get unexpected results from experiments with performance, and creating correct benchmarks is also very tricky business. One needs to be a real expert in vms to do this right. So don't expect any optimizations from me, haha :) . But if you want to work on this I'll gladly merge the PRs, but you will have to start from creating some benchmarks, so we would be sure those optimization work in practice :) . Or if you have a big app written using Kefir, benchmarking that app probably would be even better than synthetic micro benchmarks.
Vesa Karvonen
@polytypic
Apr 01 2017 15:23
Sounds good. I'm also not interested in trying to optimize Kefir to match Most.js. (I'm actually quite familiar with the basic techniques/ideas that Most.js relies on. For example, I experimented with stream fusion a decade ago - damn I'm getting old.) The above are just some things I've actually observed when running my own (non-automated) frontend benchmarks. So, next time I see those issues in a profiler, I'll create a PR. :)
Roman Pominov
@rpominov
Apr 01 2017 19:53
OK, sounds great!