Proposal: gqlgen performance improvements
- Vorherrschende Sprache
- Go
- Sterne
- 10.8k
- Forks
- 1.3k
- Ø Merge
- 2 T. 36 Min.
- Gemergte PRs (30 T.)
- 26
Beschreibung
In our monorepo, with ~140 `.graphql` files spread across 3 different apps (i.e different gqlgen config files), `gqlgen` takes ~74s to execute.
This time has been creeping up over time as the team is adding new graphql surface area and the time it takes to regenerate files is in the critical path both for development iteration (graphql files have to be generated and then the Go server has to rebuilt) and in CI (for verifying that there are no changes to checked in generated files). The above timing is inclusive of everything we tried to speed this `gqlgen` up like `skip_validation: true` and `skip_mod_tidy: true`.
After some profiling, it seems like most of the time is spent inside `packages.Load` with `NeedTypes` where it forks `go list -json` which triggers partial compilation. From my research, it seems like there might be places where we can avoid this costly operation.
I want to take a stab at implementing a few performance improvements to make generation much faster (~10x improvement seems achievable from experimentation). My plan is to validate gqlgen changes by switching our internal build to use a fork and then if viable, contribute the improvements upstream.
Is there an existing on-going effort to speed up gqlgen that I should be aware of before I start? Outside of the existing unit tests, are there other means to validating my changes?
Beitragsleitfaden
Bewertung
Dieses Issue wurde noch nicht bewertet.