gomock() does a full Go compile of the library on which it depends? #2
Comments
|
Whoa, this ticket got missed. I’m not sure why that’s happening. (Maybe this is related to your PR?) |
|
Just to clarify: this is independent of the PR. Even when doing local builds (both with and without my patch being applied), I see this behaviour. |
|
hm, I'm not sure how much control bazel_gomock has over this. We might have to take this over to the rules_go repo to figure out. |
|
It's plausible that you're seeing the cost of reconstructing the gopath by copying files around. Would you mind putting up a reproduction somewhere? |
|
Sure! Just check out https://github.com/EdSchouten/bazel-buildbarn and run |
|
Thank you! |
|
Ah! I shoved this into the bazel's tracing stuff and it was really in the compile step and then I remembered why: https://github.com/golang/mock/blob/3b08ada96ed40e57fe7a70f2e4d5858e8dfd9af2/mockgen/reflect.go#L115 Mockgen works by generating and then compiling a Go program that includes your lib to generate the interfaces it needs. But, because the Does that sound like what you were seeing? A few possible fixes:
|
|
Ah! mockgen provides a That means we can rig this up in bazel easily! So, we have a 4th option:
|
|
mockgen's flags, of course, completely rule and I think I'll email the devs to thank them for those. |
This dramatically speeds up mock generation by letting mockgen use bazel's cache and build graph. We use mockgen's `-prog_only` and `-exec_only` modes to split up mockgen's generation of the interface printing program and mockgen's use of that program to generate the actual mock code. By doing that, mockgen no longer runs the `go` binary to build the interface printing code which transitively builds the entire GOPATH we created. Fixes #2
|
I've posted PR #6. I've tested with your codebase and my private one and it works much, much faster. I'm going to timebox adding some tests. The bazel testing story seems a bit rough, but I'm hoping I can at least get the golden paths. |
|
That //pkg/mocks:ac, for instance, generates about 10 seconds faster for me. Below is a trace of that target with this new mock generation code. It was generated with (It's really JSON, but the |
|
Just tested it. Indeed: it speeds up builds significantly for me. Thanks a lot! |
This dramatically speeds up mock generation by letting mockgen use bazel's cache and build graph. We use mockgen's `-prog_only` and `-exec_only` modes to split up mockgen's generation of the interface printing program and mockgen's use of that program to generate the actual mock code. By doing that, mockgen no longer runs the `go` binary to build the interface printing code which transitively builds the entire GOPATH we created. Fixes #2
This dramatically speeds up mock generation by letting mockgen use bazel's cache and build graph. We use mockgen's `-prog_only` and `-exec_only` modes to split up mockgen's generation of the interface printing program and mockgen's use of that program to generate the actual mock code. By doing that, mockgen no longer runs the `go` binary to build the interface printing code which transitively builds the entire GOPATH we created. Fixes #2
I notice that if I make a small change to my code, I need to spend 15-ish seconds afterwards to regenerate the appropriate mock. Running
top, I see that it runs a log of Go compile processes during that time.Is it truly necessary to spend a lot of time compiling stuff at that point? Couldn't the already compiled results be used for that?
The text was updated successfully, but these errors were encountered: