Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are currently migrating to the new Apollo codegen.
The new codegen tool runs for over 30 minutes and uses a lot of memory to generate the latest Swift types, and our CI is failing to complete. I suspect this thread might be related to apollographql/apollo-ios#3434.
I am opening this pull request to propose changes and gather feedback from the repo authors.
What is happening?
Whenever the RootFieldBuilder builds named fragments via buildNamedFragmentSpread. The codegen flow will eventually reuse a previously built fragment from BuiltFragmentStorage. Once resolved, a NamedFragment type would be returned by the codegen flow and will use the Entity fields to build up the EntitySelectionTree in the Selection Set which references the fragment.
The fragments resolved from BuiltFragmentStorage are eventually referenced to it's previously created swift file.
Some fragments can contain very large amounts of Entity fields which might not be relevant for referencing intents.
With this pull request, I propose adding support for partial NamedFragment to reduce the amount of data merged into the EntitySelectionTree.
The intention of partial fragments is to return a NamedFragment which contain entities necessary for referencing intents. (ex: field for inlineFragments, references for referencedFragments etc.)
In this example, I am reducing the number of entities filtered out that have FieldPaths deeper than 3 (?)
What is outcome?
With this change, the same swift output is generated according to our schema, but the duration is reduced from 30 minutes to 3 minutes, and memory usage has decreased to 400 MB.