Performance when adding many subscriptions at once

[dorbaruchh]

Hello,
I'm working on a page that includes a table and a filtering column. The table is showing 50 rows.
Right now when a filter is modified and the table data changes, there is a noticeable lag.
It seems that the performance issue is coming from a column that renders a component that is subscribing to about 3 different endpoints because when I remove this specific column the filtering performance improves significantly.
The component doesn't have other logic or expensive computation that might explain the performance issue.
I was wondering if removing and then adding relatively many subscriptions at once (at most 50 subscription removed and 50 added) is expected to cause some lag, or is this explanation unlikely and I should look elsewhere?

Thanks!

[markerikson]

Can you clarify what you mean by "subscriptions"?

The only "subscriptions" in Redux Toolkit are when components use a useGetSomeDataQuery hook from RTK Query, where a "subscription" is a reference counter.

Are you talking about React-Redux and store subscriptions instead? Or is this indeed RTKQ?

Can you show a CodeSandbox or a repo of what you're trying to do?

[markerikson]

@zkbule oh my. Yeah, if you're doing a JSON.stringify() of the entire state every time, and your state has any real size or depth to it, that's going to be expensive. Please don't do that!

Is there a reason why you feel you need to make a full clone of the Redux state for every action?

At most, I'd suggest passing along the current action contents, but not the whole state.

[zkbule]

@zkbule oh my. Yeah, if you're doing a JSON.stringify() of the entire state every time, and your state has any real size or depth to it, that's going to be expensive. Please don't do that!

Is there a reason why you feel you need to make a full clone of the Redux state for every action?

At most, I'd suggest passing along the current action contents, but not the whole state.

Yea...I realize that. Actually the most time consuming part is the trackEvent, not the json stringfy. And you are right, I'm logging action payload now instead of store state. Do you have any idea why it's not impact the thunk + reselect approach?

[markerikson]

I would expect this to impact thunks and normal actions as well, because it was running on every dispatched action.

[zkbule]

I would expect this to impact thunks and normal actions as well, because it was running on every dispatched action.

I wish I can show you my thunk version with the listener. One question, isn't the effect in listener supposed to be async? So the expensive operation in the effect shouldn't impact the overall action dispatch? (I know it's bad...but just out of curiosity)

[markerikson]

@zkbule : no, listeners run synchronously as part of the overall dispatch sequence, just like any other code in a middleware. Even if you mark the effect function as async, all the code up until the first await is still synchronous:

startAppListening({
  actionCreator: todoAdded,
  effect: async (action, listenerApi) => {
    console.log("This runs sync as part of the dispatch");
    await listenerApi.delay(1);
    console.log("This runs in a new event loop tick");
  }
})

(Of course, any expensive code that takes a long time to run is still going to block the event loop for that long, no matter whether it's in a click handler or a setTimeout or after an await - it's just a question of when that expensive code runs.)

And yeah, if you can show a more realistic example of what you've got in your app atm, that would be helpful, especially if it's a sandbox I can run and look at.