Performance issues when unmounting useLiveQuery due to excessive setTimeout and clearTimeout calls

[amiran-gorgazjan]

• I've validated the bug against the latest version of DB packages

Describe the bug
Apps with large numbers of live queries, when unmounting them, trigger deferred garbage collection via setTimeout. setTimeout has a considerable performance impact and looking at the profiler, about half of the entire time spent for a re-render gets spent creating and clearing garbage collection timeouts.

To Reproduce

Steps to reproduce the behavior:

1. Create some view with a large list of data, say tweets paginated, 500 per page
2. Each Tweet component gets the tweet id passed down as a prop and it gets its own data using it's own useLiveQuery instance to optimise for minimal updates when mutating
3. Swap between pages. Each of the 500 tweets will get unmounted and 500 new tweets should be re-mounted.
4. Observe performance via any Profiler
5. The performance is quite bad, depending on the number of tweets making the page almost unusable

Expected behavior
I expect the performance to be relatively reasonable.

Screenshots
Loads and loads of unmounts:

And most of that time is spent in setTimeout and clearTimeout calls:

Desktop (please complete the following information):

• OS: OSX
• Browser: Chrome
• Version: 145.0.7632.117 (Official Build) (arm64)

Additional context

Can be fixed with a centralised garbage collection queue: the function calls could be pushed to an in-memory queue which is triggered for deferred consumption, doing setTimeout only once during the unmounting process. The individual setTimeout calls will thanks to this happen after the render process.

I tested this in a fork and it gave me 2x performance when using StrictMode where the setTimeouts happen twice per unmount.

[kevin-dp]

Hi @amiran-gorgazjan,

Did you test the branch with our WIP for subqueries to see if that solves those performance issues? You can try out subqueries, we currently have 2 open PRs #1298 and #1307

If you need aggregates or toArray then you need to use the first PR, if you need to reference parent fields from the subquery then you will need the latter PR. We want to merge those PRs soon and release them but you can already give it a try now to see if that would solve your isses.

[amiran-gorgazjan]

Did you test the branch with our WIP for subqueries to see if that solves those performance issues?

The subqueries are really good for what they are and can definitely improve performance and most likely our team will wait until subqueries are supported and stable before starting migration to Tanstack DB + ElectricSQL from our own custom sync engine.

However, they don't directly address the performance issue when the type of architectural choice is made that is described in the issue, which is leaf components accessing the data directly via queries using query subset matching. This type of architecture is beneficial for both readability and debuggability but also for optimistic mutation performance.

To clear it up, this is the type of architectural choice I'm talking about:

function Parent() {
    const { data, isLoading } = useLiveQuery(
        q.from({ user: usersCollection })
    )

    if (isLoading) return <div>Loading...</div>

    return <ul>
        {data.map((user) => (
            <Child key={user.id} id={user.id} />
        ))}
    </ul>
}

function Child({ id }) {
    const { data } = useLiveQuery(
        q.from({ user: usersCollection }).where(({ user }) => eq(user.id, id))
    )

    return <li>{data.name}</li>
}

Given 100 users, this will create 100+1 subscriptions to the data. Only the parent will cause an actual GET/POST to the ElectricSQL endpoint and thanks to query subset matching the Child components will not cause a fetch and directly read the data.

Our current code extensively uses this approach and our own Zustand-based in-house sync engine is optimised to deal with it, since it's just basic selectors to the store. If we wanted to migrate to Tanstack DB, it would be preferable if we can minimise the amount of architectural change it introduces, so making performance optimisations that don't require refactoring the architecture would help us (and others) to make the choice of migrating to Tanstack DB easier.

I improved the performance of this case in my PR: #1326

[kevin-dp]

Closing this as fixed by #1326