Serious Lag - traced back to 'handling commit changeset' + flushsync

Our Retool project is a main table, where each record has a button that opens up a modal with a tabbed container, which displays drilled down details for that record.

We optimized our approach for making database queries and loading data, to get around some limitations and performance issues related that were slowing the rendering. Now, once loading the project, when opening a record for the first time, the data loads quickly and everything is great. However, after closing the record, opening up subsequent records presents significant lag. Between a few seconds, and up to 10s of seconds.

The Retool Debug Tools makes it look everything is okay, and that everything loads within 1 second. Rather frustrating, when you're watching it take 10 seconds or more to open the modal and load data.

Chrome's Dev Tools seem to indicate the culprit:
Each time when opening a record we can see in Dev Tools dozens of entries in console for 'Performance log: handling commit changeset: 20.12343 ms' (each item with different amount of time).
When opening a record for the first time, nearly all the those values are 10-30ms. But for subsequent queries, a whole bunch of the 'handling commit changeset' entries are 250-400+ms.
When following the entries into the sources panel, they all point to queueMicrotask and (it seems particularly) flushSync. (Incidentally, when I looked up flushSync, React's Reference Docs warns and cautions against using it except in last resort.)

It appears the issue at hand has to do with significant lag in clearing the values that are previously loaded. And that it why opening a record for the first time does not present the issue. We've tried to clear the values ourselves when closing the record opening using component.clearValue() and query.reset(), in order that when opening a subsequent record the values are already clear. That didn't help. We continued to see the same bloated times for handling commit changeset.

Any insights or suggestions? Would very much appreciate any help!

Hi @Diskin,

I'll surface this internally & see what we can find :slightly_smiling_face:

In regards to the app structure (main table->modal->tabbed container), it may be worth moving the tabbed container contents to another app. For performance reasons, we generally recommend creating smaller apps that are linked together rather than combining all functionality into one app.

We'll have some exciting updates coming up in regards to linking apps together. For the time being, we typically recommend using url params to pass data between apps (for example, passing the id of the selected row of a table to the url for a separate app that will drill down on that record).

1 Like

Hi @Diskin,

Can you share an export of your app (feel free to send to me directly) and a sample record?

Why not use localstorage? Its better the url parameters? I have the same use case almost. A table and a button on each row to open a new app with more details of that client selected

1 Like

Thanks for chiming in! Yes, sounds like local storage would work well too :slightly_smiling_face:

1 Like