[discussion] Can we make RxJS stack traces shallower?

[radex]

Performance work is 50% optimizing code and 50% unwinding RxJS stack traces
~ me, half-jokingly

I've been working a lot lately with performance inspector for my project, and this is what I've been dealing with:

To get to my app's functions, I have to expand so many RxJS functions, I literally run out of space on my 24'' display. That's how unreasonably many of them are there.

Of course this is a different case of the same problem as when dealing with errors that are somewhere deep in RxJS stack trace - #2663. Both make the developer experience of working with RxJS really frustrating.

Now, my question is — why are RxJS stack traces so deep? On my count, the screenshot has just 4 rx operations - switchMap, switchMap, distinctUntilChanged, ReplaySubject.

Is this level of depth truly necessary for RxJS's functionality? performance? Do we really need to go through subscriber → subscriber → next → _next → next → __tryOrUnsub → subscriber on every operator?

Or is it just an unfortunate side effect of whatever convention/structure/something that was used, and could be easily, at least partly, remedied by some basic refactoring and folding multiple functions into one?

Or if this is because of performance, could we make the stack traces shallower in debug?

[cartant]

@benlesh has been working on re-writing the underlying implementation and his mutable-subscriber approach should address this. Have a look at this branch, if you are curious: https://github.com/ReactiveX/rxjs/tree/experiment-mutable-subscribers

As to why things are the way they are, my understanding is that it's that way for performance reasons. Reasons that are - AFAICT - historical. Closures used to be much more expensive and the current, class-based implementation had perf advantages. This is no longer the case.

[radex]

Hi @benlesh -- is this problem going to improve with version 7?