useBaseQuery onSubscribe is slow when mounting lots of useQuery instances

[dwilt]

First off: we have a pretty intense React application. We use useMemo, useCallback and React.memo pretty intensely to reduce re-renders. And these have had huge wins from a performance perspective. We recently just migrated from useSWR to RQ because it handles infinite scrolling better. However, one thing I'm seeing that is a bit concerning is the overall performance of the application seems significantly worse. We're using notifyOnChangeProps: 'tracked' to reduce re-renders which has been important to keep parity with how useSWR tracks which props are used. I'm not sure if we're missing some sort of config option but given that we have so many components on one page which utilize some query hook, whenever we change pages, there seem to be hundreds of RQ hooks which mount. And using the performance profiler in Chrome, everything is pointing to useBaseQuery's onSubscribe call.

Take a look below at me navigating between pages in our application. You can see a bit of lag in the transition.

Again, it's worth noting that there are hundreds (at least) of query hook instances on this page. All of the assets on the screen, links in the side bar, and virtually everything else, probably have some RQ hook nested somewhere in them.

See this video showing more in-depth:

Does anyone have any ideas?

[TkDodo]

I'd be happy to look into this with you. I always advocate for just calling useQuery wherever you need the data, but of course creating an observer is not for free. However, it shouldn't be that expensive I think.
Does it behave like that in production as well?
A codesandbox reproduction would be great - maybe just some dummy app where the same query is mounted a hundred times or so...

[dwilt]

Thanks for your offering to help. And yes, it does behave like this in production as well. If you sign up with our application at air.inc, and add a lot of assets to 2 boards, I think you'll be able to replicate this.

I'd love to do a screenshare with you. Can you find some time on my calendar? Hopefully sooner than later 😅

[TkDodo]

do you have a workspace you can invite me to that shows this? I signed up as dominik@dorfmeister.cc

[dwilt]

do you have a workspace you can invite me to that shows this? I signed up as dominik@dorfmeister.cc

Go sign up at qa.air.inc. This is our development server. I just sent you an invite to my workspace with these exact boards I'm showing in the video.

[dwilt]

I also just added you to my Slack so we could talk there if you'd like as well. We're debugging this at the moment

[dwilt]

@TkDodo I've put together a CodeSandbox showing our issue. When there are 100 items on the screen, with 8 observers in each item, at 6x slowdown, they take about a 1.2s to mount and about 750ms to unmount. You can see the entire thread is locked up for that time with all of the event listeners being added/removed.

[dwilt]

@tomaszczura is doing some testing to see how much better it would make our app. He's modifying the lib code in his local node_modules to test.

Probably something still that would be a good thing to add in, no? Why clear a timer if it doesn't exist?

[TkDodo]

Probably something still that would be a good thing to add in, no? Why clear a timer if it doesn't exist?

yes, I would accept a PR that adds that fix :)

[TkDodo]

here's a quick benchmark showing that clearTimeout(undefind) slows everything down 5x:

https://jsbench.me/mjl4ybxzwe/1

[dwilt]

We're having a bit of trouble replicating the benefits on our side.. can you post up a codesandbox of the example with the improvement your seeing?

[TkDodo]

Hm, I'm using this sandbox: https://codesandbox.io/s/react-typescript-forked-67gdwl?file=/src/App.tsx

note that I set initialData, so the queryFn isn't really called. I did that to take re-renderings out of the equation from when data comes in, because that is something we cannot influence.

But we still call clearTimeout unnecessarily. The infinity staleTime would only help to avoid creating timers. So things should be better after we wrap the clearTimeout call in an if statement.

[dwilt]

Update: After talking with @TkDodo (thanks for your help), we think the best approach here is to just reduce the number of usages of useQuery. There are a bunch of instances of them that we can move up to the top of our application and only have one instance since they don't update very often. In short, using useQuery has a bit of overhead (like useSWR) and if you have a lot of elements with a lot of instances per element, this can seriously add up because of the way observers are added and removed on mount and unmount.

To show an example of our change, we previously had a component on our screen with a useQuery like this:

Before:

// here's one of our reusable hooks that got used in a lot of places
const useSubscription = () => {
  const { currentWorkspace } = useCurrentWorkspace();
  const subscriptionKey = getSubscriptionKey(currentWorkspace?.id);
  
  return useQuery(subscriptionKey);
}

// here's how it was used and this component could be rendered dozens of times
// and in a virtualized list so improving the mount/unmount time is super important
const myComponent = () => {
  const { data: subscription } = useSubscription();
}

Since the user's subscription really never changed, and to save the perf, we moved the useSubscription hook to Context and now we don't have the issue of unmounting and remounting of observers:

After:

export const SubscriptionProvider = ({ children }: SubscriptionProviderProps) => {
  // we don't destructure `isLoading` to reduce re-renders since Context API sucks at that
  const { data, error } = useSubscription();

  const value = useMemo(() => ({ data, error }), [data, error]);

  return <SubscriptionProviderContext.Provider value={value}>{children}</SubscriptionProviderContext.Provider>;
};

export const useSubscriptionContext = () => {
  const context = useContext(SubscriptionProviderContext);

  if (context === defaultValue) {
    const error = 'SubscriptionProviderContext used outside of SubscriptionProvider';

    if (isDevStage()) {
      throw error;
    } else {
      handleTryCatchError({
        error,
        context: error,
      });
    }
  }

  return context;
};

// and then in our component
const myComponent = () => {
  const { data: subscription } = useSubscriptionContext();
}