We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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 version go version devel +377a2cb2d2 Tue Mar 27 18:03:39 2018 +0000 linux/amd64
Consider:
func f() { workBuf := make([]int, 0, 32) // ... do some local work on workBuf }
-m says
-m
f make([]int, 0, 32) does not escape
and workBuf is stack-allocated. But if the make line is changed to
workBuf
make
n := 32 workBuf := make([]int, 0, n)
the workBuf variable is heap-allocated: make([]int, 0, n) escapes to heap.
make([]int, 0, n) escapes to heap
You can still get a stack allocation by making n a const:
n
const
const n = 32 workBuf := make([]int, 0, n)
it may be worth to extend the stack-allocation optimization to include bounds defined in local, non-escaping variables.
The text was updated successfully, but these errors were encountered:
Please see also #20533
Sorry, something went wrong.
Ah! Thank you. Basically a dup of that one... closing here.
No branches or pull requests
Consider:
-m
saysand
workBuf
is stack-allocated. But if themake
line is changed tothe
workBuf
variable is heap-allocated:make([]int, 0, n) escapes to heap
.You can still get a stack allocation by making
n
aconst
:it may be worth to extend the stack-allocation optimization to include bounds defined in local, non-escaping variables.
The text was updated successfully, but these errors were encountered: