useFragment is not scalable as the number of fragment grows

[hanlindev]

Issue Description

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.

We created a sample app to help reproduce the issue. Please refer to the Link to Reproduction.

The question was originally posted on the community forum, creating this issue so the Apollo team can track this.

Link to Reproduction

https://github.com/jashmoreindeed/apollo-client-performance

Reproduction Steps

See the README for the apollo-client-performance repo.

@apollo/client version

3.8.10

[jerelmiller]

Thanks for reporting this @hanlindev! The reproduction and thorough analysis on your end really helps. Thanks so much!

I'm hoping we can consider this for 3.10 as we'll be doing some fragment related work anyways. No guarantees, but I will certainly discuss it with the team. Thanks!

[vladar]

@hanlindev useFragment without data masking will be definitely an overhead. The repro doesn't seem to use @nonreactive directive, but I suspect the result will be similar even with it.

We did see similar problems in our project and introduced a custom @mask directive as a direct replacement for @nonreactive. It introduces a proper masking and minimizes the overhead of useFragment. I've opened a PR as a reference implementation of @mask directive, maybe you can try it with your repro?

[michaelfaith]

@jerelmiller curious where the team landed on timing / priority for resolving this in the context of your larger fragment work? We've been unable to upgrade past 3.8.8 due to this performance issue.

[jerelmiller]

@michaelfaith we have not prioritized this yet. I'm curious why you're unable to upgrade anything past 3.8.8? Are you running into other issues upgrading to 3.8.9? That release was fairly small and removed more than it added so it makes me curious.

While we haven't looked into this particular issue deeper, I can point to a couple things that have been released since 3.8.8 that may be of interest on the performance side.

3.8.9 had a fix for excessive cache.watch calls in useFragment you should at least see a slight bump here since there should be less setup/teardown of watches between renders.

3.9 introduced some new memory management improvements with a new LRU cache for some of the internal caches. You might try upgrading to 3.9 or later and checking the internal cache usage to see if you're bumping against any of those limits. Many times perf issues are due to the inMemoryCache.executeSelectionSet and inMemoryCache.executeSubSelectedArray caches hitting their limits. Not a guarantee thats what you're running into, but worth investigating.

3.9.10 added a small optimization that would bail out of the executeSubSelectedArray calls for empty arrays which should improve performance in some queries that contain empty arrays.

3.11.5 did a small bit of work in useFragment that helps improve compatibility with React Compiler. This change updated useFragment to try and optimize the number of times the memoized options changed when updates to non-key fields were made to the object passed to from. This should reduce the number of times the cache watch operation was triggered due to a change in options.

Lastly, 3.12.0 introduced data masking which essentially works the same as applying @nonreactive to all fragment spreads in queries or other parent fragments. This can improve render performance by only rerendering the useFragments for fragment data that changes rather than having query components rerender as well.

I can't guarantee that any of these improve what you're seeing, but you might give some of these versions a try and see if you have any improvement. We have not yet taken a deeper look at some of the cache functionality to see what kinds of improvements we can make there, so if the issues you're running into have to do with functions like diffQueryAgainstStore, you likely wouldn't benefit from the above mentioned changes. If you have anything else that you can share about what you're running into, that would be super helpful. I still can't guarantee a timeline right now as our priority has shifted to getting 4.0 moved forward and out the door. I'm hoping at least one of these versions help something on your end 🤞

[michaelfaith]

@jerelmiller thanks so much for the detailed response. I don't believe we gave 3.8.9 a chance, specifically, but 3.8.10 was where we hit a wall. It's been several months since we tried an upgrade, since there hadn't been any movement on this issue. So I'll give it a shot with the information you laid out and let you know how it goes. Thanks again

[jerelmiller]

Huh, I'm very surprised 3.8.10 had much of an impact. The only notable changes in there since 3.8.9 were a fix to the serialization of a console warning and a new value compared in an if statement. The other changes are updates to dev dependencies or tests. I'm very curious now if you see a regression in 3.8.9 since that one had more significant changes.