Use sparse Maps rather than dense sources arrays in mergeType code.

[sachindshinde]

From @benjamn :

In the mergeType code responsible for merging subgraphs schemas into a supergraph schema, I noticed we were often looping over a sources array with as many elements as the number of subgraphs, inside a loop over all the fields currently being merged, leading to running time proportional to the product of the number of subgraphs and the total number of fields being merged.

This PR demonstrates that we can instead represent just the contributions from various subgraphs that are directly relevant to the current type or field being merged, so the sources data structure does not always remain as large as the number of subgraphs. Swapping the type Sources<T> = Map<number, T | undefined> type for all the array parameters can be done without altering behavior or performance (see the 2nd commit), and that foundation enables the sparse representation optimization (preserving behavior while improving performance; see the addFieldsShallow changes in the 3rd commit).

[changeset-bot]

🦋 Changeset detected

Latest commit: f5f6a79

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
@apollo/composition	Patch
@apollo/gateway	Patch
@apollo/federation-internals	Patch
@apollo/query-planner	Patch
@apollo/query-graphs	Patch
@apollo/subgraph	Patch
apollo-federation-integration-testsuite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[benjamn]

For future work: we could probably prune the Sources<T> maps even more by not including an undefined entry for every subgraph without a match for T here in the subgraphsTypes method.

However, naively omitting all undefined entries causes problems because some subgraphs are relevant (for validation, or because of @interfaceObject) even if they don't have a declaration matching T. Future investigation should identify these cases and include them in the resulting Sources<T> map.

Additionally, it might be beneficial to memoize the result of subgraphsTypes (if it turns out be called redundantly)?

[sachindshinde]

Note that when includeMissingSources is true, the absence of pairs in the Map will result in different behavior for this block down below:

if (!subgraphElt) {
  if (includeMissingSources) {
    distributionMap.add('', this.names[i]);
  }
  continue;
}