Identify several really good macro performance tests about rxjs HOT 7 CLOSED

Commenting here at the request of @Blesh.

I can't think of any concrete macro tests, but based on my measurements, perf challenges go in order of: subscribe() cost, currentThreadScheduler on synchronous producers, stack depth. In traces I've also seen a ton of AutoDetachObserver spam, but haven't been able to isolate and measure its impact since it seems cross-cutting.

With respect to subscribe, generally both on the server and client we deal with very small Observables, typically in the range of 1-10 items. That isn't to say that some other consumer won't have a firehose observable, so we should still make sure observer chains remain shallow or even collapsed via deforesting, and schedulers remain lean or even optional. However, in terms of real cases I can only speak to the significant cost of short-lived observables.

When playing with most.js, I found that while most was indeed tens of times faster than Rx for synchronous sources and operators, the following was enough to cause them to converge:

range(0, 1000).flatMap(returnValue).flatMap(returnValue).flatMap(returnValue)

Most's official flatMap tests showed a significant win because they weren't really testing flatMap/subscribe; it was a flatMap of large ranges into large ranges, which ended up being more of a benchmark of onNext, especially since synchronous sources didn't go through a scheduler at all (I don't know if that has since changed).

If we make flatMap over very small observables fast, I think the most common UI/service aggregation cases are covered. The trampolining in currentThreadScheduler is a serious perf hit though, so it's worth trying to bypass/optimize it. However, the majority of real code I've seen doesn't leverage synchronous sources nearly as often as it leverages flatMap-like operators over potentially-async sources.

I'll see if I can find some time to contribute some tests based on these observations.

from rxjs.

From RxJS meeting
Attendees: @Blesh, @trxcllnt, @steveorsomethin, @ktrott

Focus on Macro tests for places where we are creating new observables and subscribing to internal observables: zip and async ones
Macro performance will capture memory footprints: creating objects, garbage collection, etc.

TODO: Identify the list of operators that we want to focus on.

from rxjs.

Really any operator that creates objects internally such as subscriptions or observables... so for example, groupBy creates Observables internally. flatMap creates subscriptions internally. concat creates subscriptions internally.

Likewise, operators that cause any buffering, like buffer, window, subscribeOn, observeOn, etc. Should probably have accompanying macro perf tests:

• flatMap
• merge
• mergeAll
• concat
• concatAll
• subscribeOn
• observeOn
• groupBy
• groupByUntil

from rxjs.

I'm unsure if Subjects should have macro perf tests. But I think multicast might be a good idea.

Thoughts? @steveorsomethin?

from rxjs.

@Blesh It's probably wise, though designing the test is interesting. The overhead of Subject.subscribe seems minimal since it's just pushing into an observer array. Instead, I'd expect the macro bottleneck to be cases where subjects are treated as observers since Subject.onNext needs to copy its observers array every time it is invoked. Even then, that seems to only be a serious problem with large numbers of observers and firehose source observables.

from rxjs.

couple of prior arts that include Rx, might be good to see the improvement
https://github.com/spion/async-compare/ (bit out of date)
https://github.com/petkaantonov/bluebird/tree/master/benchmark (newer fork of above)
from http://spion.github.io/posts/why-i-am-switching-to-promises.html

from rxjs.

I think we've identified what we want to test for macro perf and outlined them in #100. Choosing this issue for now.

from rxjs.