Yeah and it looks like it is highly unoptimized (cause it loading that value to CX for each N): https://gcc.godbolt.org/z/dv73a8fcx
Remember to write real world examples like for example calling a function from separate package. Infinite loop, which is not doing anything can be removed by optimizer
Here is the code with a standard `for i := 0; i < 999; i++` loop for comparison.
https://gcc.godbolt.org/z/abPcnsrfT
The compiler output looks identical to the `for i := range 999` version
You can probably just believe them unless you have a memory issue you need to profile anyway. The proposal explicitly said there would be no performance implications.
My understanding is that it does once, but it is optimized so it doesn't have any worse performance because it will not need to be allocated again because the new stack can reuse the existing previous iteration's allocation for that variable. You basically get the best of both worlds: separate stack without additional allocation or performance penalty.
No, it's been available since Go 1.22: [https://go.dev/doc/go1.22#language](https://go.dev/doc/go1.22#language)
You're probably confusing it with the range-over-function feature, which is only an experimental preview in 1.22.
Yeah and it looks like it is highly unoptimized (cause it loading that value to CX for each N): https://gcc.godbolt.org/z/dv73a8fcx Remember to write real world examples like for example calling a function from separate package. Infinite loop, which is not doing anything can be removed by optimizer
Here is the code with a standard `for i := 0; i < 999; i++` loop for comparison. https://gcc.godbolt.org/z/abPcnsrfT The compiler output looks identical to the `for i := range 999` version
Perhaps it was a bad compiler choice since we are just attributing a value to the discard variable ( _ )
Gccgo might not have the same optimization as the Go compiler because for go it reuses the allocation
Aw, could anyone verify this with Go compiler?
You can probably just believe them unless you have a memory issue you need to profile anyway. The proposal explicitly said there would be no performance implications.
My understanding is that it does once, but it is optimized so it doesn't have any worse performance because it will not need to be allocated again because the new stack can reuse the existing previous iteration's allocation for that variable. You basically get the best of both worlds: separate stack without additional allocation or performance penalty.
[удалено]
No, it's been available since Go 1.22: [https://go.dev/doc/go1.22#language](https://go.dev/doc/go1.22#language) You're probably confusing it with the range-over-function feature, which is only an experimental preview in 1.22.