Also, if you tell the compiler to report memory allocations you'll see
something like this:
./x.go:10:13: inlining call to fmt.Printf
./x.go:18:13: inlining call to fmt.Printf
./x.go:7:6: moved to heap: h
./x.go:10:13: ... argument does not escape
./x.go:17:3: moved to heap: h
./x.go:18:13: ... argument does not escape
The issue isn't that the stack is growing. The issue is the `h := h`
assignment in B() is causing a new heap allocation each time through the
loop. I don't know why either var definition is escaping to the heap but
the increasing address for the B() case is because you're making 1e5
instances of that heap var.
On Tue, Mar 19, 2024 at 1:12 PM Mohamad Rostami <mb.rostam...@gmail.com>
wrote:
> Well, I used runtime runtime.MemStats StackInuse.
> I don't have much knowledge about compiler optimization.
> But to make it clear for myself:
>
> considering these 2 functions:
>
> //go:noinline
> func A() {
> var h int
> for i := 0; i < 1e5; i++ {
> h = i
> _ = h
> fmt.Printf("%+v\n", &h)
> }
> }
>
> //go:noinline
> func B() {
> for i := 0; i < 1e5; i++ {
> h := i
> _ = h
> fmt.Printf("%+v\n", &h)
> }
> }
>
> The address of h in B is changing in each iteration although it's not
> causing stack to grow.
>
> If you point me to the documentation for this specific case, I would
> appreciate it.
> Regards,
>
> On Tuesday, March 19, 2024 at 5:46:36 PM UTC+1 Ian Lance Taylor wrote:
>
>> On Tue, Mar 19, 2024 at 9:36 AM Mohamad Rostami <mb.ros...@gmail.com>
>> wrote:
>> >
>> > I've seen in many places in go source code re-declaring a variable with
>> the same name.
>> > e.g:
>> > for i < j {
>> > h := ...
>> > }
>> > Instead of
>> > var h int
>> > for i < j {
>> > h = ...
>> > }
>> >
>> > So I did a benchmark to check the differences. I didn't find any
>> performance related differences, but in terms of Stack Memory in use, the
>> second approach is better than the first one.
>> >
>> > Not sure if the way is in standard library is by intention or something
>> that should be ignored.
>>
>> The two versions are basically equivalent. How are you measuring
>> stack memory usage? If they are different, there may be something to
>> fix in the compiler.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3818a025-d46c-4e23-8b2e-6e0a08c0986an%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/3818a025-d46c-4e23-8b2e-6e0a08c0986an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8z3eUxYQkOBBMQK1%3DaKh4uKrHNWPHD%2Beo1C76W1CGZSA%40mail.gmail.com.
