Don't rerun mockgen if it's already up-to-date

[MichaelSnowden]

What changed?

I added time-based caching to our mockgen invocations in go:generate directives. The tool gets bypassed in the CI.

Why?

I run make ci-build-misc a lot during development, and I noticed that make go-generate is a huge bottleneck there, taking about 45s-1min for me. I tested our other generate directives like the rpcwrapper, but that one seems fast, it looks like mockgen is the real culprit. I tried upgrading our dep to the latest version in the Uber fork to see if there was a quick win there, but it seems even slower now somehow. I considered batching our commands as well, but there isn't a way to batch mockgen commands in source mode (multiple -source and -destination flags). So, I figured I would borrow what Make does and just only run mockgen if the generated code is stale when compared to the source code.

How did you test it?

Running make go-generate locally now takes about 7.7s, down from 44.0s, so it's about 6x as fast:

temporal  snowden/cached-mockgen [$] ➜ time make go-generate
Process go:generate directives...
make go-generate  6.74s user 5.61s system 159% cpu 7.743 total
temporal  snowden/cached-mockgen [$] took 7.7s ➜ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
temporal  main [$?] ➜ time make go-generate
Process go:generate directives...
make go-generate  68.13s user 123.43s system 435% cpu 43.955 total
temporal  main [$?] took 44.0s ➜ 

I also added unit tests which check cases like the destination file not being present, and it tested that manually as well.

Finally, I also deleted all _mock.go files and reran the command to verify that it works ok even when everything is out-of-date. In that case, there is a slight regression in time, up to 1 minute. I don't know why that's the case, but it should still be faster when there's no mocks.

Potential risks

Documentation

Is hotfix candidate?

[dnr]

In that case, there is a slight regression in time, up to 1 minute. I don't know why that's the case, but it should still be faster when there's no mocks.

I would guess that's the overhead of go run.. it has to check all the sources against its build cache.

General comment:

I'm fine with this for interactive use, but I would prefer if there was a way to make sure CI always did the full generation ignoring mod times. Mostly because I don't trust git to set mod times correctly in all cases. Could we do that with an environment variable or something that's set in CI but not interactive use?

[MichaelSnowden]

In that case, there is a slight regression in time, up to 1 minute. I don't know why that's the case, but it should still be faster when there's no mocks.

I would guess that's the overhead of go run.. it has to check all the sources against its build cache.

Great insight. I just made it use the prebuilt binary, and it now only takes 7 seconds instead of 22!

General comment:

I'm fine with this for interactive use, but I would prefer if there was a way to make sure CI always did the full generation ignoring mod times. Mostly because I don't trust git to set mod times correctly in all cases. Could we do that with an environment variable or something that's set in CI but not interactive use?

That should definitely be possible, and I agree that it's a good idea. I'll look into it.

[MichaelSnowden]

I'm fine with this for interactive use, but I would prefer if there was a way to make sure CI always did the full generation ignoring mod times. Mostly because I don't trust git to set mod times correctly in all cases. Could we do that with an environment variable or something that's set in CI but not interactive use?

I set a new BUILD_ENV environment variable in our CI, and I now check it in the tool. I confirmed that, with this set to true, the time for a full cached mockgen run (which just passes through to mockgen), is no slower than it was before (thanks to your idea about improving go run).