Thanks @kurtis,
I actually have both functions without fmt print function, so no allocation
is happening.
I also did compare assembly codes with your command, and can confirm both
are equal.
go 1.21.0 darwin/arm64
On Tuesday, March 19, 2024 at 11:20:03 PM UTC+1 Kurtis Rader wrote:
>
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: ...
I would start by building it with inlining disabled and assembler output
enabled. Then compare the assembly code for main.A and main.B.
go build -gcflags 'all=-l -S' x.go 2>y
On Tue, Mar 19, 2024 at 1:12 PM Mohamad Rostami
wrote:
> Well, I used runtime runtime.MemStats StackInuse.
> I don't
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", )
}
On Tue, Mar 19, 2024 at 9:36 AM Mohamad Rostami 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
Hi,
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
