Rxjs Subject performance - how many is too many? Is it better to try to combine several into one?

Issue

So the gist of my question. Imagine you have a service that handles 2-3-4-10 actions. And to communicate in several components, you have 2-3-4-10 Subjects.

So, is it better to have 1 subject, and pass in on next an object identifying which of the actions it relates to, and filter inside your subscription...or have the lot of them and subscribe separately?

How many subjects is too many? They more or less remain active all at once throughout.

Kind of curious in an abstract a sense as possible, rather than my own usecase and whether or not it could be done better.

Solution

I work on large angular applications that uses hundreds if not thousands of subjects (Subject, BehaviorSubject, ReplaySubject, AsyncSubject).

Is there a performance hit for using many subjects?

To this, I'd say it's not the subjects that matter, since they are only taking up memory space. It's the pipeline that you attach to them, which places them into the cpu's computation queue that matters. This is dependent on the pipelines themselves, and not the subjects. You could have a single subject that connects to a long computational heavy pipeline, which if done incorrectly, would slow your program down since javascript runs on a single thread of execution (you could use web workers to avoid this problem).

Therefore, the number of subjects is irrelavent here if we are talking about how "performant" your application is. It's the pipelines that determine if your application is slow. Ie, data moving down a pipe and having operators manipulate it.

StackBlitz single pipe that is computationally heavy to prove my point.

Is it better to have 1 subject, and pass in on next an object identifying which of the actions it relates to, and filter inside your subscription?

I would say this is more of a design decision to have a bus of information ("a single subject") passing all your data along, instead of breaking them up into their respective streams. This could be handy if your data is interconnected, meaning your events depend on each other, and if the order they appear within the stream matters (like navigation events: started, performing, ended, etc).

I would be unhappy if a dev used one giant bin to place all their data into instead of breaking it up into respective streams. Ie, if I have a user object, company information, and notifications, I'd expect these to have separation of concerns, and to not be delivered through a bus system (a single subject), but to instead be delivered through different services, with their own respective subjects and pipelines.

How many subjects is too many? They more or less remain active all at once throughout.

If you're doing trivial maps and filtering, then don't worry about how many subjects you're using. Worry about if your streams of data make logical/logistical sense, and that they are structured/siloed correctly.

StackBlitz program combining 1 million behavior subjects to prove my point.

Answered By - Kevin Baker