Open randall77 opened 7 months ago
Change https://go.dev/cl/561875 mentions this issue: cmd/compile: caching result of AlgType
Change https://go.dev/cl/561936 mentions this issue: cmd/compile: caching result of AlgType, EqCanPanic and PtrDataSize
@mdempsky
Looking at this a bit more, the exponential behavior is in both cmd/compile/internal/types.AlgType
and cmd/compile/internal/types.PtrDataSize
.
However, at tip, there are two additional offenders, cmd/compile/internal/types2.(*comparer).identical
and cmd/compile/internal/types2.(*Checker).validType0
. Those do not appear in profiles of the test case in earlier versions of Go than tip (unlike the first two). Bisect points to https://go-review.googlesource.com/c/go/+/567976 @griesemer
Change https://go.dev/cl/571543 mentions this issue: cmd/compile: compute ptrBytes during CalcSize instead of on demand
Change https://go.dev/cl/571542 mentions this issue: cmd/compile: compute type eq/hash algorithm in CalcSize instead of on demand
I will look into the validType issue again. The previously existing code was wrong, even though it helped in this case.
Go version
tip
Output of
go env
in your module/workspace:What did you do?
test.go
:Compile with
It takes a surprisingly long time. The pprof output points to
cmd/compile/internal/types/alg.go:AlgType
as the culprit. It is walking the exponential-sized object to determine its algorithm class. It should probably memoize the computation somehow so it isn't exponential.Add more lines to the example to make it even more slower.
Found during discussion in #65495.
What did you see happen?
What did you expect to see?
Fast compilation.