How many selectors can I be subscribed to before I have to worry about performance

[fast girder]

for context i have multiple 'features' in one page, each feature selects multiple slices(lets say 5 on average) of the store.
my selectors i would say are pretty basic, something like selectAll.filter(id/property)

so lets say i have 5 features in my page, thats 25 selectors/observables im subscribed to at the same time.
more features might be added on the page in the future
so how many selectors can I be subscribed to before I have to worry about performance.
just need some benchmark since if the issues starts at around maybe 80-100 i wont be worrying about it because i would never hit that amount

[delicate bone]

The slowdowns would be more from the amounts of data. If you have long @for creating components, etc.

[fast girder]

so its more about how big the 'reactions' are to the emits. rather than how many subscriptions exist. also to clarify what i meant by performance issue is more like the app feeling laggy in general, i dont mind as much the loading time of records, or refresh time for updating. for example i once made the mistake of not unsubbing and at one point had 20+ subscriptions running, everything just felt laggy even my mouse movement

now for more context, my features actually has these selectors in a service but my components only really react to one observable which is a combinelatest of all my selectors(around 5-10).
so I may be subscribed to 5 or more observables(including combinedlatest counted as 1) but only 1 is 'connected' to the component

also lets say the 'features' are just paginated grids w/ 20 records each. and the reaction to this combinelatest obs is just to refresh the 20 records.

to summarize (assuming i have 5 features with 5 observables/subscriptions each)

• only 2 observables which are the combinedlatest selectors, at a time that can cause reaction to components
• component reaction just means refreshing 20 records in a page of the grid (can happen on both features at the same time)
• other 20 just does some simple side effect like updating a variable in the service because only the services are running and the components are hidden. the remaining 3 are the combinedlatest of the selectors. which will also keep running but basically just creates the array but again no component reaction

with that in mind do you think im safe to scale up to like 10-20 features with the current design.

sorry for wall of text lol

[fast girder]

welp i manually tested it and just recreated the same combinelatest observable 200 times and subscribed to it. i didnt see any slowness or atleast it wasnt significant enough. not sure how accurate that test is but i think thats good enough for me

my question still stands though if someone has more insight on it. and any additional input is welcome. Thanks

[delicate bone]

It really comes down to the structure of the app. What series of events have to occur to render the component, and how many dom elements need to be created.