cmd/go: go cmd performance degradation on Plan 9 between Go 1.9 and 1.11 #27744
Labels
FrozenDueToAge
GoCommand
cmd/go
help wanted
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
OS-Plan9
ToolSpeed
Milestone
Comments
|
can you run |
|
I don't know what would be "weird", but: |
|
I meant to compare it with the 1.9 go fmt running under iostats. my suspicion was that you are generating a lot more 9p reads for whatever reason, which can be costly given no 'true vfs caching' in Plan 9. |
dmitshur
added
OS-Plan9
ToolSpeed
NeedsInvestigation
dmitshur
changed the title
|
@mirtchovski ah, my mistake.. the summary from the go 1.9 one is: There's a lot more walking and clunking. The most significant difference in the individual file stats (I can post the whole thing on request) is that the .git directory appears in go1.11 but not go 1.9.2. I don't know if that's enough to cause the difference, but I suspect it's walking the whole .git directory now unnecessarily. @dmitshur The problem is in |
dmitshur
changed the title
bcmills
changed the title
|
CC @0intro |
|
Yes, I confirm there is a performance regression between Go 1.9 and Go 1.10. Detailed comparison: https://www.diffchecker.com/5Dj8GNPJ |
|
Contrary to Go 1.9, Go 1.10 also scan the |
|
I'd like to point out that all the go tools are affected by this regression, not just It would probably be beneficial to start a fresh issue for this, perhaps with a title reflecting the true extent and magnitude of the problem.
|
|
As mentioned earlier, the issue is with the |
griesemer
changed the title
|
I've been testing the runtime a bit between versions and it seems like the issue with this is regarding the garbage collector. The specific major release that causes this bug to hit is go1.11, go1.10 seems to work just fine. The actual code that is causing the slow down at the start of the runtime initialization is in mccommoninit. For plan9 For reference this slow down is also seen on go1.12. Here are traces of syscalls made by go1.10.8 and go1.11.1 through the use of plan9's ratrace(1), both outputs are from running the command |
|
At this point Go 1.11 is no longer even supported, so the regression in performance is de facto the new performance baseline for the I have no objection if someone wants to contribute fixes for the general problem of Go getting slower on Plan 9, but I don't think we need to keep an open issue against |
I am unable to make sense of this statement no matter how I interpret it.
It’s not a problem of it getting slower; it’s a problem of something bad happening in the runtime. Testing on several machines shows an average of around 0.5 seconds passing before main() is even reached, so calling it the “new performance baseline” and closing the issue seems a bit absurd in the face of evidence that the runtime may no longer be behaving sanely. I found the commit that appears to mark when this problem began, but I don’t use or write go, so somebody else will have to investigate if they want to find out what is really going on. |
|
Reverting the sysFree function change in the commit BurnZeZ pointed out seems to take care of the delay. |
OK, that was mine, sorry. It seems to be only an amd64 problem: plan9 on arm and 386 are unaffected. |
|
Change https://golang.org/cl/207917 mentions this issue: |
|
As this is actively worked on, I am going to reopen this. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?go 1.11 plan9/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?GOARCH='amd64'
GOBIN=''
GOCACHE='/usr/driusan/lib/cache/go-build'
GOEXE=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='plan9'
GOOS='plan9'
GOPATH='/usr/driusan/go'
GOPROXY=''
GORACE=''
GOROOT='/usr/driusan/go1.11'
GOTMPDIR=''
GOTOOLDIR='/usr/driusan/go1.11/pkg/tool/plan9_amd64'
GCCGO='gccgo'
CC='6c'
CXX='g++'
CGO_ENABLED='0'
GOMOD=''
CGO_CFLAGS='-g -O2'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-g -O2'
CGO_FFLAGS='-g -O2'
CGO_LDFLAGS='-g -O2'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build647141787=/tmp/go-build -gno-record-gcc-switches'
What did you do?
Ran
go fmt ./...on the packagegithub.com/driusan/dgit. Load spikes to 100% and it takes over 2 minutes, while this wasn't the case with previous versions of Go.term% time $home/go1.9.2/bin/go fmt ./...
0.05u 0.11s 4.32r /usr/driusan/go1.9.2/bin/go fmt ./...
term% time $home/go1.11/bin/go fmt ./...
39.60u 1.11s 129.93r /usr/driusan/go1.11/bin/go fmt ./...
What did you expect to see?
Similar performance to previous releases in go fmt.
What did you see instead?
A 30x performance degradation.
The text was updated successfully, but these errors were encountered: