executeSubSelectedArray cache is full of empty arrays

[kgssystem]

Issue Description

Hello all,
On an application with loads of data, and especially lists, I noticed a behavior that executeSubSelectedArray cache fills up disproportionately fast to the amount of data in the application. It's a scheduling application, and we have a lot of deeply nested data - that keeps default normalization - with a lot of fields that are lists. Something like:

type Day {
  date: ISO8601Date!
  events: [Event!]!
  holidays: [Holiday!]!
  id: ID
  isConfirmed: Boolean!
  isReleased: Boolean!
  metaInfo: [MetaInfo!]!
  open: [ID!]!
  userId: ID!
}

Usually, all those lists (holidays, events, etc.) are empty, it's rare that they have some data in them. To indicate that they're empty, we return empty array from back-end/data source, which seems to be a common pattern and helps avoiding optional chaining everywhere. However, apollo client seems to treat all those empty arrays as any other array, which on one hand is correct, but it seems like treating an empty array as nothing, or frankly null, and not storing it in cache would be beneficial. In our case, returning null instead of an empty array for those lists reduced the number of entries in executeSubSelectedArray from around 6k to 2.2k. That may look like a specific case, but I believe we are following a common pattern here, and it's unexpected that >60% of executeSubSelectedArray is filled with nothing but air, or in other words empty arrays.

I've added a reproduction example where I modified the default template to include an always empty list with every person. It now creates a new entry for every person in executeSubSelectedArray, even though I'd argue treating empty array as nothing would be preferable, and it should not be cached.

Link to Reproduction

https://codesandbox.io/p/devbox/quizzical-darwin-rygm6d?workspaceId=09e55846-a4b6-4a71-876a-5fe11037e12f

Reproduction Steps

No response

@apollo/client version

3.9

[phryneas]

The point of the "cache" of executeSubSelectedArrays is not necessarily the output of an empty array, but the mapping of the input to the output:
"If for this field of this parent entitity, I make a specific query selection on it's array children, what do I get back?"

You shouldn't be concerned that this cache holds 22k elements, and most of them empty arrays. It's still valuable information, as in these 15k "extra" cases, all of them come "from different inputs".
It just means that the next time this result is requested from the cache, you don't have to execute 22k functions instead - it's a performance optimization.

[phryneas]

That said, we could get around this for the specific case of empty arrays, but it has some tradeoffs.
I opened #11670, but am not sure if it's actually worth it following through - see potential discussion there.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.