RTK Query: Performance issues with upsertQueryData, makes UI hang

[ceisele-r]

Hi,

I am using RTK Query to load a folder (potentially with children) from a network endpoint in a RTK API Query endpoint named getFolder.

The folder object returned from the network looks like this:

{
  id: "123",
  "name": "Folder",
  children: [
    {id: "456", name: "Child 1", children: []}
    {id: "789", name: "Child 2", children: []}
    ...
  ]
}

My endpoint looks like this:

getFolder: builder.query<IFolder, { folderID: string; requiresLoadedChildren: boolean; }>({
      queryFn: async (args, queryApi) => {
        // Perform network request
        ...
          return {
            data: objectFolder,
          };
        } catch (err) {
          return {
            error: ResolveError(err),
          };
        }
      },
      providesTags: (result, err, args) => [{ type: "Folder", id: args.folderID, loadChildren: args.requiresLoadedChildren }],
      onQueryStarted: async (args, queryApi) => {
        const { data: fsObjectFolder } = await queryApi.queryFulfilled;

        // Upsert for all children
        const upsertPromises: QueryActionCreatorResult<
          QueryDefinition<...>
        >[] = [];
        fsObjectFolder.children.forEach((baseFsObject) => {
              upsertPromises.push(
                queryApi.dispatch(
                  folderApi.util.upsertQueryData("getFolder", { folderID: baseFsObject.id, requiresLoadedChildren: false }, baseFsObject),
                ),
              );
        });
        await Promise.all(upsertPromises);
      },
    }),

So my goal is to load a folder using the getFolder query and if its returned object has children, upsert the information for each child for the getFolder endpoint (without children).
The goal is to have all children already in the cache so other queries to the getFolder endpoint (with requiresLoadedChildren: false) can immediately access the cached data.

However, the upsert code seems to create performance issues as it causes the UI to hang for several seconds even if there are only ~700 children returned / upserted.
When profiling in Chrome, I can see that the onQueryStarted takes ~350ms followed by two anonymous functions from redux (the first taking ~600ms, the second taking ~1s) causing a total hang of ~2s:

I'm actually not sure what the anonymous functions from redux are but even the ~350ms for the onQueryStarted (containing the upserts) feels very long to me for "only" ~700 items.

Is my general code for the upsert correct or is there potential to optimize it?
Is it normal that the upsert takes that time?
Or is there a possibility to batch upserts together so that no ~700 dispatches have to be made?

Would it be beneficial to the performance to leverage createEntityAdapter somehow? Unfortunately I did not find an example how to use createEntityAdapter with my desired purpose because I'm also upserting multiple endpoints using the children data (depending on the type of the child).

I mean it's not that of an issue that it takes its time but what's problematic is that it freezes the UI during the upserts.

Any help or hint whether this performance is "normal" is appreciated.
Thank you!

[markerikson]

Hi! Funny you should ask this :) I actually literally have a draft PR up that adds a new util for doing batched upserts with much better perf:

• [DRAFT] Implement a util function to batch-upsert cache entries #4561

Could you try out the CodeSandbox CI build from that PR and see how that affects the performance?

And yes, the relatively slow perf you're seeing is in a sense "expected". upsertQueryData uses the normal async thunk flow, which involves dispatching a separate pending and fulfilled action for each item. That also means 2 * N calls to the Redux store root reducer, all the Immer immutable update logic, and calling all the store subscribers afterwards.

[ceisele-r]

Hi @markerikson , thank you for your fast response and the explanation.

Uuh that's nice! 😃

Performance looks waaay better using your new build.
In the first tests I'm now down to ~75ms for the onQueryStarted for the same data set and this overall Task is down to ~95ms as I'm also no longer seeing the anonymous function calls after the onQueryStarted in the profiler (even in a debug build compared to a production build used previously).

And now the UI no longer freezes (or it's so short it isn't noticeable).

This is a massive noticeable improvement in the performance and I'm looking forward to it being shipped 👏 🚀

One thing I noticed when trying it - maybe it's not yet correct in the types or it changed compared to upsertQueryData (however I could not fully extract that info from the PR):
Are the queryApi.dispatch(myApi.util.upsertEntries(myUpserts)); calls async, so should they be awaited?
Because typescript infers it's a synchronous call - when awaiting it tells me 'await' has no effect on the type of this expression.ts(80007).
However, the upsertQueryData thunk was indeed async (was also described in the docs here https://redux-toolkit.js.org/rtk-query/api/created-api/api-slice-utils#description-1) and it was correctly inferred by TS.

[EskiMojo14]

no, upsertEntries is just an action that gets dispatched synchronously.

[markerikson]

Yeah, upsertQueryData is an async thunk that adds one cache entry and dispatches two actions async, while upsertEntries is a single sync action that accepts many entries as its payload.

[ceisele-r]

Alright, perfect, thank you!