code-generator
code-generator copied to clipboard
kubernetes
performance drop with GO111MODULE="on"
export GO111MODULE="on" and then run any of the code generators (so far defaulter-gen, deepcopy-gen, conversion-gen) for a pretty drastic increase in time to run vs export GO111MODULE="off" first.
I've been converting https://sigs.k8s.io/kind over to modules fully, and observed this performance issue, I've not yet had a chance to dig into why this occurs, but ensuring that module mode is set to off while calling the code generators seems to dramatically improve peformance.
This might be because go mod will download all the dependencies of the project, rather than looking at the vendor directory (if it hasn't pulled them down already?). May want to try with -mod=vendor enabled?
Just a thought.
I don't think that's it but I'm not 100% certain. The performance difference can be observed with a populated vendor and module cache just between running GO111MODULE="on" <code-generator> and GO111MODULE="off" <code-generator>. The code generator code performance seems to be tied to this.
So far a viable work around to embrace modules is:
- build the code generators while module mode is enabled (so you can install the version your module tracks)
-
go mod vendorto populate vendor locally from your module cache - disable module mode
export GO111MODULE="off" - fake a
GOPATHwith a tempdir and a symlink to the repo - run the generators
- cleanup the fake gopath
This is a bit hacky, but allows everything to use modules and doesn't have the big performance penalty.
Implementation here: https://github.com/kubernetes-sigs/kind/blob/10642f530782963ed23b3d4a14587950bbacaa63/hack/update-generated.sh
@BenTheElder Can you try with GO111MODULE="on" GOFLAGS="-mod=vendor" <code-generator> as well? We're about to hit this in cluster-api soon :)
@vincepri feel free to give it a shot in the kind repo, we're still using the workaround detailed above for now. I might not get to this for a bit myself :sweat_smile: The fake gopath part is pretty trivial and either way we need the rest of the wrapper to populate vendor etc. if it's going to use vendor instead of the module cache
Oops, sorry I missed the other comment above yours which suggested the same. I wonder how this will perform with the latest build of code-generator, which should be using tools/packages to retrieve the modules.
I'll update when I can test in CAPI or kind.
latest build of code-generator, which should be using tools/packages to retrieve the modules.
@vincepri do you have a link to an issue/PR about this? Afaik gengo, the main generation tool behind code-generator, would need to move to using tools/packages first and I don't think that's going to happen soon-ish because that would result in breaking lots of existing interfaces.
cc @sttts
@nikhita I think I might have talked too soon :smile:. We should definitely get this on the roadmap, maybe with a feature flag and documentation to opt in?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
/lifecycle frozen this issue is not going away on it's own and it will probably bite us in the future, FYI @liggitt @dims (be aware of this when touching k/k build scripts...)
FWIW i'm no longer using the vendor / GOPATH workaround in kind, but I've also changed a lot of things:
- less code
- less dependencies
- less use of generators
- go1.15rc1 ...
Could this change landing in Go 1.18 help here? 🤔 https://github.com/golang/go/issues/44435
I don't think so. That issue seems to relate to populating dependencies in the module cache more quickly. Module mode slows the generators significantly independently of that step.
@thockin: Closing this issue.
In response to this:
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
any context around how/why this is closed ? Seems like there was no activity for three years and it was closed - is that it or it was "fixed" somehow ?
An answer in parts.
- Yes, module mode is slower because Go's libs internally call
exec("go", "list", "-json")and then parse the results. - It's not as much slower now as it was when this was filed.
- Continuing to support non-modules mode in k/k was a burden, which we have decided not to carry. We stopped running codegen on every
makeand we adopted go workspaces.
IOW, Go's packages and related libs could get faster, but we no longer consider it "a problem".