-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: escape analysis on closures #39511
Comments
Potentially related to #18300 |
There's a general limitation that I don't think there's anything that can be done specially here, unfortunately. |
Knowing nothing about compiler optimization, is it possible to lift the closure in the more allocating benchmark to be declared similar to the less allocating one? |
Theoretically, yes. But cmd/compile doesn't implement any optimizations like that currently. This is #22081. |
Thanks! Interesting, I thought this would be more similar to for loop variable lifting that I remember @josharian mentioning in the past. |
You're right that it's conceptually similar. The key difference is lifting variables across call frames has implications on calling conventions, whereas lifting them out of a loop only affects how that function itself is compiled. |
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?
What did you expect to see?
I expect
BenchmarkLoopEach
to perform the same asBenchmarkLoopEachSaved
. Preferably, I would also like to seeBenchmarkLoopEach
not allocate.What did you see instead?
In the former, the closure is allocated inside every
j
iteration inLoopEach
whilev
is allocated once per benchmark iteration. In the latter, the closure,v
, andoi
are allocated once per benchmark iteration.go test -gcflags '-m -m'
OutputThe text was updated successfully, but these errors were encountered: