New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: long build time (45 seconds) for a small package (1500 source lines of code) #65097
Comments
i believe this is working as expected as the standard library is not precompiled as part of the distribution but part of the user build cache. |
The first go build command reconstructs the cache, including the standard library.
The second build command, the one that is timed, only builds the tree package.
Therefore, i do not think this is the normal behavior.
|
Reopening. Thanks for the easy reproducer @thomaspeugeot. |
is there antivirus or other endpoint security software on the machine? and where does it spend its time if you use |
No |
I can reproduce locally on my Linux machine. The time is spent actually running I looked at a CPU profile and it's not obvious what's wrong, but there's a lot of GC. A heap profile shows a bunch of SSA-related allocations but I don't have enough experience debugging the compiler to know what's wrong based on that. The heap grows to 2.5 GB when compiling this which seems excessive? If I had to guess, something about this code causes the compiler to generate a rather large/inefficient internal representation of something. |
BTW, it doesn't take 45s for me, but about 10s. I'm on a beefy desktop machine, though. I compared to a few other Go programs of similar size and compiling them (when deps are cached) takes roughly 200-500ms for me, so it's still >1 order of magnitude slower than I'd expect. |
maybe it's the generics like with #51957 ? though there's less code here |
A brief look at cpu and mem profiles I can see that the compiler is taking a beating to compile all the switch statements over generics in the code. Edit: a lot of time spent in ssa.Compile, cse, deadcode and prove passes |
Go version
go version go1.21.5 darwin/amd64
Output of
go env
in your module/workspace:What did you do?
below are the steps to reproduce the timing result
on macos
the sed command is to trick the compiler to dirty its cache.
note for other plateforms, the sed command is different, it is
sed -i 's/gongtree_buttons/gongtree_buttons_new/g' tree.go
What did you see happen?
go build -v 46.99s user 2.44s system 371% cpu 13.320 total
What did you expect to see?
less than a few seconds
The text was updated successfully, but these errors were encountered: