Rxjs: flatMap performance

[cortopy]

The following filtering of an ObservableArray is extremely slow and resource hungry:

myobserver
  .flatMap(el => {return el; })
  .filter(el => {return !el.property; })
  .subscribe(validEl => {
    console.log(validEl);
  });

However, this isn't:

myobserver
  .subscribe(arr => {
    let filteredArr = arr.filter(el => { return !el.property; });
    console.log(filteredArr);
  });

A quick look at my laptop resources shows that the former takes CPU usage over the roof. Having tried different variations this only happens when I use the flatMap operator. switchMap has same results. I'm puzzled about this as the array's length is only 300

myobserver is an ObservableR returned by a BehaviourSubjectT

issue wrongly originally reported as https://github.com/Reactive-Extensions/RxJS/issues/1238

[trxcllnt]

@cortopy could you provide more information to reproduce this behavior (sample data, etc.), or maybe a PR with a new performance test? I can't replicate your issue.

[benlesh]

Same. I'm unable to replicate this issue. Do you have sample code or a JSBin or something?

[jadbox]

@cortopy Also, what browser/Nodejs version are you using?

[cortopy]

This is an Electron app developed in Angular 2. I'm not sure I could easily replicate it on JSBin

However, I have just been profiling CPU usage and it seems to point in the direction of subscriber methods. As mentioned earlier this is a small array of 200-250 elements, and the results are very puzzling to me.

In addition to this I've done some benchmarking as suggested. Unfortunately the --csv option didn't seem to work, so can only post txt format
rxjs_perf.txt

In regards to env, this is the stack:

Electron: 1.2.0 (includes Chrome 51)
Node: 6.1.0
Angular 2: rc1

[trxcllnt]

@cortopy it's difficult to discern whether this is an issue with Rx, Electron, or the example you're profiling.

The presence of an observeOn operation in the profiler screenshot seems like a red flag. Do you have Chrome's async callstacks turned off? And it seems like you're mixing Rx 4 and Rx 5, which isn't necessarily advisable. Additionally, the mergeMap perf numbers in the text file are reporting a net gain against Rx 4, which seems to indicate Rx 5 mergeMap is working as expected.

I'd be happy to investigate further if you can distill the issue down to a bare-bones test case that I can load into Electron and profile myself.

[staltz]

Also, try choosing switchMap over flatMap as much as possible. Use flatMap only when you know that you need concurrency.

[benlesh]

Since we can't replicate this perf bug, I'm going to close the issue for now. @cortopy if you're able to present a minimal example showing the perf bug, please do reopen this, because it would definitely be something we'd want to fix.

Thanks for filing the issue, sorry we couldn't locate any problems on our end.

[cortopy]

Considering the culprits could be many, I'll just keep an eye and see if I can reproduce this somehow somewhere. Thanks for the input

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.