OK, thank you everyone :) Le samedi 2 août 2025 à 01:02:41 UTC+2, peterGo a écrit :
> On Friday, August 1, 2025 at 4:39:17 PM UTC-4 Pierre Durand wrote: > > I think it's related to the fact that b.Loop() disables some > optimizations, but I'm not sure. > > > Pierre, > > The difference between b.N and b.Loop is a known issue. It is by design, > > https://groups.google.com/g/golang-nuts/c/Z017c0f59vY/m/AY1-wT0OBAAJ > > Peter > > > Le vendredi 1 août 2025 à 22:33:56 UTC+2, Pierre Durand a écrit : > > I can reproduce the issue with this code > https://github.com/pierrre/go-libs/blob/31bec3f12a86382924cc0b486c2008db062a14bd/runtimeutil/runtimeutil_test.go#L101-L118 > Sorry I can't write a smaller code snippet, because I think it's related > to escape analysis, and I don't fully understand it. > > As you can see, I'm benchmarking the same function WriteFrames() with the > old and the new benchmarking methods. > > When I run the benchmark, here is the result > > go test -v -run=^$ -bench="^BenchmarkWriteFrames" -benchmem ./runtimeutil > goos: linux > goarch: amd64 > pkg: github.com/pierrre/go-libs/runtimeutil > cpu: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz > BenchmarkWriteFrames > BenchmarkWriteFrames-12 366825 3091 ns/op > 0 B/op 0 allocs/op > BenchmarkWriteFramesNew > BenchmarkWriteFramesNew-12 328620 3445 ns/op > 80 B/op 4 allocs/op > PASS > ok github.com/pierrre/go-libs/runtimeutil 2.303s > > > > Le ven. 1 août 2025 à 22:04, Junyang Shao <shaoj...@google.com> a écrit : > > > > Hello Pierre, > > > > Thank you for bringing up this issue. > > > > May you share the code snippet that triggers this behavior? Thanks. > > > > > On Fri, Aug 1, 2025 at 12:50 PM Pierre Durand <pierre...@gmail.com> > wrote: > >> > >> Hello > >> > >> I noticed a weird behavior when I'm benchmarking with testing.B.Loop() > code that uses iterators . > >> The benchmark shows allocations where I start to iterate the iterator, > and where I declare variables (before the loop) that are used inside the > iterator loop. > >> I know that my code is not doing any allocation, so it's strange. > >> If I change my benchmark to use the old "range b.N", then it doesn't > show this strange behavior. > >> If I check allocations with "testing.AllocsPerRun", I don't see any > allocation. > >> > >> Is that a know issue ? Should I open a bug ? > >> What should I do ? Use the old benchmarking method ? > >> > >> Regards > >> > >> -- > >> 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...@googlegroups.com. > >> To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/70456dc1-3380-40fd-951d-e52275bc48a5n%40googlegroups.com > . > > > > > > > > -- > > Thanks, > > Junyang > > > > -- > Pierre Durand > > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/6328c3ac-fc30-4255-ad72-882d0e4b3c56n%40googlegroups.com.
