Repository navigation
perf(generator): generating a large client is 3.5x faster and the generator builds with 45% less CPU - #139
Merged
Conversation
…erator builds with 45% less CPU On a 3.3 MB spec (1094 types), generation drops from about 520ms to 150ms, and a cold build of the generator from 75s to 41s of CPU, which is most of what `go tool` spends in a CI job without a build cache. Output is byte-identical. - WriteFiles no longer runs goimports, which rebuilt its environment for every file. It fixes imports against a fixed stdlib table and gofmts, printing large files in parallel chunks split at blank lines between top-level declarations. x/tools and x/mod leave go.mod. - Templates render concurrently. - The parser calls libopenapi's datamodel packages directly. The root package also compiled its diffing, Arazzo and Swagger 2 models. - JSON specs skip libyaml: a JSON scanner builds the identical node tree, deferring to libyaml for anything it cannot reproduce exactly. - The index skips diagnostic metadata the generator never reads.
This was referenced Oct 21, 2026
feat: releases ship prebuilt binaries, so CI can download the generator instead of compiling it
#141
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Core's SDK freshness job spent 26s of its Go SDK step compiling the generator and about 1.6s generating. This cuts both. Output on core's spec is byte-identical to canary.
Measured on core's 3.3 MB spec (1094 types):
go build -aChanges
x/tools.WriteFilesnow fixes imports against a fixed stdlib table (fixImports) and gofmts. Unit tests cover adding, pruning, collapsing to a single import, sibling-file names, shadowing locals, and struct-literal keys.FileSetcopy becausetoken.Filelocks on every position lookup, which serialized the chunks. operations.go prints in 6ms instead of 48ms.libopenapiimport. The parser callsdatamodel,low/v3andhigh/v3directly, asBuildV3Modeldoes, so the diffing, Arazzo and Swagger 2 packages no longer compile.parseJSONNodebuilds the same node tree (kinds, tags, styles, values, lines, columns), verified node by node against libyaml on every testdata spec and on core's spec. It defers to libyaml for\/, surrogate escapes, a BOM, or invalid JSON. Parse drops from 105ms to 48ms.SkipMetadataCollection. The analyzer never reads the index's diagnostic metadata.Tried and dropped: building component schemas in parallel before the analyzer, and raising GOGC. Both were slower end to end.
Testing
go test -race ./...passes, including the generate-and-compile e2e tests.diff -ris empty.