Quick noob performance question
I LOVE the idea behind tanstack-db and really want to switch to it. Our app has to be extremely fast and shows hundreds and hundreds of cells in grids on the screen at a time (with tabs that we tab back and forth to see diff grids). It uses redux currently and is optimized to death to make sure it stays fast but comes at a cost of a LOT of code to get it to stay fast. Switching the code in the cell component, from our current pre-keyed redux and rereselects to a useLiveQuery, removes a ton of code and simplifies everything BUT I'm seeing it rendering much more slowly. It becomes more noticeable the more grids and cells that are showing. It's not doing any updates to the store , I'm just tabbing back and forth and the component is rendering the data. The orderCollection is just js objects keyed by an id string. The useLiveQuery I'm using is basically as simple as this:
export const useOrderQuery = <T>(a: string, b: string, c: string): T[] => {
return useLiveQuery(q =>
q
.from({ item: orderCollection })
.where(({ item }) => eq(item.a, a))
.where(({ item }) => eq(item.b, b))
.where(({ item }) => eq(item.c, c))
.orderBy(({ item }) => item.e, 'desc')
.limit(1)
);
};
Am I doing something wrong? Is there a way to make this perform faster? I tried splitting up the collection into diff collections as well to break up the data and shrink the query but that didn't seem to make much difference either.
Apologies ahead of time if I'm doing something stupid. Again, I'd really love for this to be as fast because it would make an absolutely massive difference to our code base.
Thanks...
12 Replies
extended-salmon•6d ago
so is this a query per cell?
extended-yellowOP•6d ago
Sadly, yes 🙂
extended-salmon•6d ago
you're on the latest version of db?
once the where clauses run, how many items are left to order?
extended-yellowOP•6d ago
Yes, on the latest version. In my dev version I'mn trying it's only one left that's ordered. An it's usually only one, but it can be at times a couple but never more than 10.
extended-salmon•6d ago
hmm gotcha — yeah this should be fast as the where clauses use indexes to do the matching so curious it's not — something to dig into — do you think you could make a little standalone version for us to look at and profile? cc @samwillis @kevindp (who have been working on a ton of speedups)
extended-yellowOP•6d ago
It would take some time as I'll have to carve it out of a giant app but yeah, can do...
I can't tell you how much code reduction using tanstack would cause. It'd be amazing. I'll work on a standalone and let you guys know....
Thank you for the insanely fast response...
extended-salmon•6d ago
🙏
this is exactly the sort of thing we want to make lightning quick so helping us dig in would be wonderful!
extended-yellowOP•6d ago
Fantastic
correct-apricot•6d ago
Hey @Scott R
When you navigate back and forth are you recreating the source collection that you query, or is it lifted up so that it's long lived in the app?
On first query we create indexes on the params you match, it could be that it's recreating these indexes on each navigation. That's my first hunch.
flat-fuchsia•6d ago
I guess hijacking this question a little bit, is there a more standard/idiomatic way to use queries to get a single value? For example, I have some state derived from multiple parent collections, but I only ever need a single instance of the derived state at a time (since that's what the UI supports). I could make a collection of the derived state and write a query to get my single value, but that seems a bit odd with the semantics of useLiveQuery since that always returns an array.
extended-salmon•6d ago
follow this issue! https://github.com/TanStack/db/issues/182
GitHub
add a
.findOne() to query build to return the first item · Issue...e.g. instead of: const { data: users } = useLiveQuery( (q) => q .from({ usersCollection }) .where(
@usersCollection.id, =, userId), [userId] ) const user = users[0] We could write: const { da...extended-yellowOP•5d ago
It's lifted up. I'll start working on a scaled down sample as soon as I can. It's a lot of code so it'll take a bit to whittle it down though.