In our organization, we are planning to encourage the use of fragments among individual teams so they can independently manage their own data requirements without affecting the main host app or other teams.
However, we discovered that the number of fragments has a significant impact on the site speed, specifically time-to-interactive. Through performance profiling, we are pretty certain that it is caused by two factors:
- The identify function to obtain the cache ID (our GraphQL types have non-ID primary key fields)
- The in memory cache’s diffQueryAgainstStore function.
Each useFragment invokation would cause us a few ms to even more than 10ms.
Has anyone else observed this and I’m wondering if there is any existing solution to this before we attempt our own workaround.
Hey @hanlindev 
This is the first we’ve heard of useFragment having scaling issues so that is definitely interesting! We’re sorry to hear that!
We’ve had reports about similar issues on useQuery (Scalability when many `useQuery` are used · Issue #10322 · apollographql/apollo-client · GitHub) which would also use diffQueryAgainstStore so perhaps this might be related?
That being said, I’d love if you could try 2 things for me:
- We released 3.8.9 last week which included a fix for
useFragment that caused excessive cache.watch calls on every render. Would you mind trying this version to see if you have any improvement here?
- Our upcoming 3.9.0 release has many improvements for memory management that might also help here. You can read more about it here: Apollo Client 3.9 Feature Spotlight – The memory story | Apollo GraphQL Blog. Would you be willing to try out the 3.9 release candidate and see if this improves your situation any?
Thanks for the quick reply!
We used a similar profiling strategy as the #10322, so our root cause should be the same.
I think I tried 3.8.9 and it didn’t help much. I can confirm again tomorrow if that’s the case.
But I haven’t tried the RC. I can do that tomorrow as well. Just to make sure I’m looking at the correct package. Were you referring to this one: @apollo/client - npm (npmjs.com)?
Yes! You can install it with npm i @apollo/client@next since we publish our prereleases under the next tag. Looking forward to hearing back!
1 Like
Just tried RC and it didn’t help improve the performance.
Looking at the date and popularity of the linked issue above, I’m wondering if improving the InMemoryCache read efficiency is on the team’s schedule. In the browser’s performance profiling results, the diffAgainstQueryStore is the lowest level I could go so I’m not sure which part of it is the root cause for the slowdown. Anyways, If the team needs more information, please let me know.
Dang, I was hoping you’d see at least something. At least this means we can rule out the underlying caches as being a potential issue.
Any information and/or reproduction would be great! Alternatively a replay would also be useful so we can dig into the code a bit more and see where we might be getting issues.
Would you be willing to open a new issue so we can track this? Any information you can provide in there would be super helpful so we can find areas for optimization. Thanks!
Just created the issue on Github. On the ticket, I linked the sample app repo we used in our performance analysis.
Fantastic. Thanks @hanlindev! No guarantees, but I’m hoping we can consider this for 3.10.0. I really appreciate the reproduction!