Go build speed dependent on time after source modification

[Mark Fletcher]

I recently migrated from a 2019 i9 Macbook Pro to a new M1 Max Macbook Pro (64GB on both machines), and to my surprise, my go build times ended up being the same. I started to do some research, and I've found a curious behavior that I'm hoping someone can shed some light on. This is with go 1.17.2, vendored dependencies, in a large project.

For my test, I'm just changing a fmt.Printf() in one source file, to hopefully avoid any caching.

Here's the strange thing. If I do a 'go build' within ~12 seconds of saving that change, my build time is about 16 seconds. If I save that change and wait at least 13 seconds, my build time drops to about 2 seconds. This is repeatable. I run the binary after each build, and can see the changed printf(), so I know it's being compiled.

I then looked at the output of 'go build -x' in each instance, and there are a couple of differences. In the case where I don't wait after saving, at the start of the build, it creates a _gomod_.go file. And then, it runs a compile, which takes the majority of the 16 seconds. In the case where I wait at least 13 seconds after saving the source file, the build does neither of these steps.

Any thoughts/suggestions would be appreciated.

Mark

[Brian Hatfield]

This seems a little like you might have a background compilation process occurring which is populating the build cache. What editor environment are you using? Is it possible it is effectively running compilations on your code, whether via IDE support, indirectly via linters, or other on-save actions?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7fcd831f-b89e-4319-9190-fba199efd5d0n%40googlegroups.com.

[Mark Fletcher]

On Thu, Nov 4, 2021 at 10:25 AM Brian Hatfield <bmhat...@gmail.com> wrote:

This seems a little like you might have a background compilation process occurring which is populating the build cache. What editor environment are you using? Is it possible it is effectively running compilations on your code, whether via IDE support, indirectly via linters, or other on-save actions?

Hmm, well I think you're right. I use VSCode, which runs gopls. It never occured to me that gopls would run a compile, but I guess in hindsight it makes sense. If I shut down VSCode and instead edit the file using vi, I get consistent 16 second compile times regardless of how long I wait. So, thanks for the suggestion. I still don't understand why my compile times are the same between the i9 and M1 Max, but I guess I need to do some more research.

Thanks,

Mark

[Alberto Donizetti]

Could be due to https://github.com/golang/go/issues/48496

Should be fixed on tip, but 1.17 is affected.

Alberto

[Mark Fletcher]

On Fri, Nov 5, 2021 at 5:10 AM Alberto Donizetti <alb.do...@gmail.com> wrote:

Could be due to https://github.com/golang/go/issues/48496

Should be fixed on tip, but 1.17 is affected.

Thanks for this pointer. I just tested this and it made a huge difference. For a change to a single file, compiling on 1.17.2 takes ~14 seconds. On tip, it takes ~5 seconds.

Mark