T
TanStack•this hour
typical-coral

useQueries slowing down the app (freezing for several seconds)

We recently started to use useQueries extensively when querying our entities throughout our apps. We use granular query for each entity and combine them using a list of ids and building each granular queries into useQueries to get the entire list of entities. As opposed to before where we had an endpoint returning all entities. our queries (eg: useUnits) are therefore spawining useQueries with hundred of queries attached in many components. This led to explosion of our performances. Note that there are almost no re-render so its not the issue, the issue is likely internal and an overhead of maybe overusing useQueries. When we log the queryCache events, there are millions of logs happening Here is an example of a hook that is being used in many places export const useUnits = (ids: string[]) => { return useQueries({ queries: ids.map(id => createUnitQuery(...)) }) } Maybe we naivily assumed it would be fine but it seems not, it is freezing the app seversl seconds. There are not even that much entities anyway, the volume is about <= 100 ids.
12 Replies
like-gold
like-gold•23h ago
Could you give an example of the endpoint?
typical-coral
typical-coralOP•23h ago
I dont think this is related to endpoint, The issue is not network lag but runtime freeze. This is a regular REST API as mentioned, we have only a few re-render, it is very optimized on that part. For a hundred of entities, we have a hundred re-render (we only watch data property) the millions of logs I am talking about is when we log the queryCache events. Most logs are observer updates / mount / unmount etc
fair-rose
fair-rose•23h ago
can you show a reproduction?
typical-coral
typical-coralOP•23h ago
I cannot share the app but I could try to make a reproduction yes. Will take some time later to do it
fair-rose
fair-rose•23h ago
yes there will be one observer for each created query but it shouldn't matter much it could be related to structural sharing, not sure. Try turning that off to see if it gets better
typical-coral
typical-coralOP•23h ago
lemme try to turn it off on the default options yeah. also some interesting things I found while digging. During dev (react dev build) the app freeze for 3-4 seconds. On the same action on the production build, it only takes 300ms. My assumption is that, there is a lot of "trashing" happening somewhere (maybe because of the looping of observers triggering sync external store events). This makes it even more obvious on react dev build. the billions queryCache logs makes me think that at least. structural sharing disabled does not change it. Btw, another interesting thing going from v5.81 to 5.90 increased the freeze by about 2 seconds consistently
fair-rose
fair-rose•23h ago
there have been a couple of "fixes" for useQueries in there. can you narrow down the exact version?
typical-coral
typical-coralOP•22h ago
5.90.2 There is a chance we over-use useQueries. I mean it's fair to assume that it does have a cost anyway. It's probably also fair to assume that useQueries for 100 entities is much less performant than one useQuery. I didn't think it would be "perceivable" tho
fair-rose
fair-rose•22h ago
5.90.2 didn't have runtime changes, only type-level ones 😅
typical-coral
typical-coralOP•22h ago
I meant from 0.81. probably many changes
fair-rose
fair-rose•22h ago
yeah, please narrow it down 🙂
typical-coral
typical-coralOP•22h ago
Yes, in fact there may be two issues. First one being the way we do things and second one likely a degradation of performance between versions. I will try to narrow it down

Did you find this page helpful?