Zero Allocations And Benchmarking In Golang

[@anthonygg_]

► Join my Discord community for free education discord.com/invite/bDy8t4b3Rz ► Become a Patreon for more exclusive content www.patreon.com/anthonygg_ Thanks for watching

[@lying6624]

That's some next level content. Subscribed! I've also checked others videos. Seems like a gold cave.I hope you will continue to deliver quality content

[@GoWithAndy-cp8tz]

Hi ! Anthony are you Italian? The way you express yourself and the tempo of your explanations makes me think that you are living in a place with lots of sun. That's very interesting topic you bring up. I always was curious what is underneath. Now I'm able do dig in a little. Cheers!

[@ParanoYa1117]

This was very informative, thanks for that quick hands on video. I think maybe you should have created the buffer inside the bench function, so that the relevant allocation would show. Because for me, when I run it 100x and create the buffer once inside the bench-loop (b.N); I get 6 allocations. Only then I could actually measure/see a difference in behavior when calling buf.Reset() after each iteration

[@xodzphone]

I am a fan. Cant wait to reconstruct my pure java apps with golang

[@aggellos2001]

Excellent video 🤌

[@prasannadiwadkar8153]

Excellent informative.

[@sovrinfo]

Awesome, Big Thanks!

[@evarlast]

I would like to see the next step. Writing foo 100 times doesn't cause buffer to expand because of the default backing store size of buffer. In production it is very common for that buffer to be some large json which is bigger than that default buffer size. We may even know the size if we read the content-length of an http response. Show how to reduce allocations when filling a buffer in this case.

[@anthonygg_]

Well, good point. For big big data you would probably increase initial buffer size. That would imply custom buffer stuff I guess.

[@mhcbon4606]

if you use pooling technique, the buffer s being re used, chances are their sizes stabilizes and allocs reduce past the first iterations.

[@KishoreKumarVaishnav]

@anthonygg_ Nice video. I see the inner loop iterates over the variable i which is already been used by the outer loop. This causes the inner loop to iterate indefinitely and will cause the program to crash. You should use the loop variable j instead of i in the inner loop. Correct me if my understanding is wrong?

[@baxiry.]

both i has two different scops. There is no conflict for the compiler. But yes. There will be confusion in reading the code. for i := 1; i < 5; i++ { fmt.Println("-------------", i) for i := 100; i < 105; i++ { fmt.Println( i) } }

[@damiendeuley]

hi, thanks for the video, can you tell us what is your color theme on vs-code ? it looks so good haha

[@anthonygg_]

Gruvbox

[@user-ey7rp6bl2n]

if you starts programing in C/C++ you alway thimnking aout allocations! And first time i also always think about dealoocation))))

[@asutoshpanda1508]

need a full-stack app that covers in depth concepts with proper industry practice, that can give me a job if I put that in resume and as golang will be used, we can try out few new ideas and go out of the box

[@mhcbon4606]

zero clue how the code is being optimized in those trivial tests. It s quiet important to understand that it can drastically change the results, thus the observations.

[@vladmoroz660]

Why is the allocs/op zero, but B/op is not zero in the last execution?

[@dazealex]

It's because the buffer is allocated, but it needs to grow by B bytes.

[@vladmoroz660]

@@dazealex ok, thx. But why “growing by B bytes” isn’t considered as allocation in op? What is the difference? As I know, in order to grow buffer, runtime has to allocate new data in memory? Am I wrong?

[@dazealex]

@@vladmoroz660 i believe it just moves the buff len params. over pre allocations. / len and cap check the docs

[@deNudge]

How about var buf bytes.Buffer?

[@dazealex]

Same thing really.

[@ThaiNguyen-gg8xj]

Some so called golang seniors don't know this 😂

[@dazealex]

Hey I know about this. :) But I wouldn't call myself Senior at all. Fell into writing Go for a project, then wrote more and more.