Most commonly no impact. It can require an additional heap allocation per iteration if taking the address or capturing in a closure, but even in those cases escape analysis may be able to determine that the value can remain on the stack because it will not remain referenced longer than the current loop iteration. If that happens then this change has no impact.

I'm not sure how thorough Go's escape analysis is, but nearly all programs that capture the loop variable in a closure and are not buggy right now could be shown to have that closure not escape by a sufficient thorough escape analysis. On the other hand for existing buggy programs, then perf hit is the same as assigning a variable and capturing that (the normal fix for the bug).

Google saw no statistically significant change in their benchmarks or internal applications.

https://github.com/golang/go/wiki/LoopvarExperiment#will-the...

Nonexistent? It can still reuse the memory if you don't capture it. And if you were capturing it "properly" it was already making a copy.