#Devtools performance

29 messages · Page 1 of 1 (latest)

worn shard
#

Hi all,

My post is related to Devtools. I'm facing severe performance issues as soon as Devtools are open and my queryCache contains a certain number of queries (>50). The query keys are built from a key factory and are then structured (array of 1 Object) and sometimes long.

I had no time yet to setup a codesandbox but I made a (bad) video to illustrate the problem, based on the basic React example.

It looks like the Devtools are performing lookups in the cache too often, leading to an important number of calls to hashKey, which has a cost since serialising a lot of objects. The more queries you have, the worse it gets.

In the video, the queryCache has been hydrated with ~130 queries from our app.

My knowledge of SolidJS is almost null but I tried to add some logs in Devtools to highlight the time spent in the "state" callback:

const queryState = createSubscribeToQueryCacheBatcher((queryCache) => {
  console.time('queryState callback')
  const state = queryCache().find({
    queryKey: props.query.queryKey,
  })?.state
  console.timeEnd('queryState callback')
  return state
})

On first load, the state callback is pretty quick to execute but it is executed a lot. Maybe ok since the first load?
On navigation, we can see that it is still executed quickly but there are way more calls to it.

Does anyone experiment the same issue? I could keep on diving on this but my knowledge of SolidJS might be a show-stopper…

Thanks!

severe estuary
#

@left cave FYI

worn shard
#

I add some logs

#

Looks like the queryCache is not constant (which might explain some extra reactivity…)

worn shard
#

Actually prevCache is always undefined in the above sample…

worldly osprey
#

I've noticed the same in 4.35.7 but figured it was just the weird environment I'm working in. If you have an issue open happy to add to it as well.

#

The equality check in your logging function is always going to fail though isn't it, because you can't compare objects like that (which the query is going to come back as) with normal equality operators? You have to use something like lodash.

worn shard
#

hi thanks for your feedback.

#

=== in the case above should compare references. I wanted to check that the 2 objects are the same in memory <=> same pointer

#

Here, I'm expected that the queryClient and the queryCache remains the same object. There are no reasons for them to change since there is only one instance of queryClient in the basic test.

#

The test fails because due to my lack of knowledge of SolidJS… createMemo does not seem to return the previous version, maybe because it is not called in a render step…

worn shard
#

In setupQueryCacheSubscription, I have the impression that we keep on subscribing and performing microtasks (getting query states etc.). According to the logs below, we do a lot of micro tasking each time a navigation link is clicked.

#

@severe estuary do you think an issue would be worth it right now? Or should we wait for people with knowledge to confirm the problem?

left cave
#

Hey there! Apologies was on a holiday this past week. Is there a way you can make your reproduction public? I can definitely work on improving the performance here

worn shard
#

Hey, please note that you don't have to apology for being on holidays 😅. I'll try to setup a codesandbox ASAP

worn shard
#

It is the "basic" Tanstack Query example, with a sanitized state containing 138 queries. I did not find a way to profile the app on codesandbox directly. The best way is to:

  • open it locally
  • start profiling
  • click on 1 post link

You should see something like that:

#

Please do not hesitate to ping me if needed, it would be interested to look at SolidJS this way. Thanks.

left cave
# worn shard It is the "basic" Tanstack Query example, with a sanitized state containing 138 ...

Thank you so much for the detailed breakdown. I have identified the issue. And I already am working on a fix. The issue was that each query row in the table would setup it's own subscription to the queryCache and update for any event whenever the cache was updated. I've made that logic smarter and now it's definitely a huge difference in perf. I'll test it out more before pushing a new release of the devtools

worn shard
#

Awesome! That's great news.

#

I may have some questions regarding SolidJS after having read the code of the Devtools. I'll wait for the release to see what has changed and ask accordingly.

left cave
#

There is a HUGE perf boost now. Same example with old implementation

worn shard
#

🔥

worn shard
#

Tested and approved! Thanks, this is a game changer

left cave