-
Notifications
You must be signed in to change notification settings - Fork 18k
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
go/internal/gcimporter: too much CPU wasted in token.(*File).SetLines
called from fakeFileSet
#46586
Comments
I'm surprise that |
@cuonglm, my bad, you are right. I haven't realized that there are two very similar types with the same name in different packages. If you look at the attached CPU profile, you'll see my mistake. Sorry. But it doesn't really matter. The hotspot looks exactly the same, just resides in a different file. |
cc @findleyr |
The problem still persists on Go 1.17. The profile taken on Go 1.17 shows that |
I can (and want) to implement a fix. The thing is that I don't know all the design considerations so I don't see the big picture. I propose two local solutions for the problem both changing public API of
What do you think? |
I don't think As a somewhat dirty alternative, gcimporter could break out the |
Another alternative might be to not set lines that we don't need
Not the cleanest fix but I think it would reduce the CPU cost significantly without requiring any API changes or use of unsafe. |
token.(*File).SetLines
called from fakeFileSet
token.(*File).SetLines
called from fakeFileSet
Change https://golang.org/cl/357291 mentions this issue: |
CL 357291 reduces the execution time of (note that this CL is in x/tools, by convenience, but I'll update the standard library importer as well). |
Change https://golang.org/cl/357429 mentions this issue: |
This is a clean port of CL 357291 from x/tools. For #46586 Change-Id: Ib22087ae7fe8477d368acd230b263b83cdad4d36 Reviewed-on: https://go-review.googlesource.com/c/go/+/357429 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org>
@g7r thank you for the detailed report, and for offering to fix this. Also let me acknowledge that getting little feedback for months and then having someone send a fix is probably an unsatisfying interaction. Sorry about that. Our attentions are sliced pretty thin for this cycle and while I saw this issue go by, I didn't really have time to think about it until it popped up this week in another context. If there didn't happen to be a workaround, I think we'd have welcomed a proposal. Thanks again for your help getting this fixed. |
@findleyr, the problem is going to be fixed after all. That's the reason I've made this report. Thanks for the effort! |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I'm trying to deal with long
go vet
execution times for our codebase. My previous issue was #46564. Hopefully, its PR will be merged soon. The next CPU hotspot I've hit into istoken.(*File).SetLines
function. It is being called fromfakeFileSet
code https://github.com/golang/go/blob/master/src/cmd/compile/internal/importer/support.go#L39-L47 :We see that
fakeLines
int slice with contents like{0, 1, 2, ...}
is being fed intoSetLines
. Here'sSetLines
implementation https://github.com/golang/go/blob/master/src/go/token/position.go#L178-L192 :So we have a rather large constant slice with 65536 elements being validated again and again in a hot code path.
SetLines
function takes up to 60% of total CPU time in my benchmarks. I'm ready to implement a fix for that problem but I'm kind of limited with ideas. Is it possible to add a separate function likeSetFakeLines
that will use internal known to be valid line slice? Or maybe we don't need to callSetLines
infakeFileSet
at all?See attached profile: cpu.prof.gz
Screenshot:
The text was updated successfully, but these errors were encountered: