Understanding Allocations: the Stack and the Heap - GopherCon SG 2019

Подписаться 5 тыс.

Просмотров 67 тыс.

50% 1

Speaker: Jacob Walker, Ardan Labs (@jcbwlkr)
Like C, Go uses both stack and heap memory. How can a Gopher know which is being used? Can you influence this decision? What effect does it have on your program? Are there any tools to help? This talk answers those questions and more.
About the speaker
Jacob is a software developer, community organizer, and has really nice hair. Like ridiculously nice hair.
He started his career creating web applications in PHP, Ruby, and Node.js. When he discovered Go he dove in deep and hasn’t regretted it for a minute. He is now a Community Engineer with Ardan Labs where he is focused on helping members of the Go community.
Event Page: 2019.gophercon.sg

Опубликовано:

26 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 55

@HSharpknifeedge 3 года назад

So far, this is the best explanation of Escape Analysis, comparing with many others, which are right now on the right side of the screen, suggesting by RU-vid. Awesome, thanks again!

@jaredcastro8862 2 года назад

I also agree. Clean and short

@ugur_dincer 4 года назад

Clear and smooth, also io.Reader part was nice

@nyashachiroro2531 Год назад

It was super nice. Literally an aha moment for me. This was a great talk.

@TehKarmalizer 8 месяцев назад

It made me think of similar functions in other garbage collected languages differently as well.

@wentaoqiu4072 3 года назад

Simply amazing, points are clear and explained throughly, thanks so much.

@Pherecydes 7 месяцев назад

I hadn't understood why the io.Reader interface works the way it does... now I get it, thank you! Excellent talk.

@kamilziemian995 3 года назад

21:20 Great ending point to great presentation.

@anaray567 Год назад

This clear why io.Reader is designed the way it is ! Very clear and precise presentation ! Thanks

@thepolyglotprogrammer 3 года назад

Really good example about the io.Reader.

@nicksypteras8594 2 года назад

That io.Reader example at the end was great!

@ideaparkcc 8 месяцев назад

It can be concluded that: system api should not be responsible for resources management (most of times it refers to memory), but only for logical evaluation.

@jub0bs Год назад

Excellent talk!

@Wielorybkek 7 месяцев назад

That was super interesting, I've learnt a new thing!

@a_maxed_out_handle_of_30_chars 2 года назад

wow, I came looking for copper and found gold

@luqmansen 4 года назад

Great explanation!

@alex6161 Год назад

The best explanation, thank you Jacob !

@kevingeorge3983 5 лет назад

awesome

@Mimookrokodill 4 месяца назад

Awesome

@speedTurtle Год назад

Cogent. I learned something here.

@rogeriof2315 2 года назад

Really nice explanation!!!

@CLE2022 Год назад

This is really good

@vamsikrishnasiddu3525 2 года назад

Amazing explanation

@АлександрКостюченко-у4х 2 года назад

He is really good. Thank you!

@slabchan7310 3 года назад

Thanks for sharing

@edb75001 3 года назад

Very informative... much appreciated.

@kanybekmomukeev4116 Год назад

Best of best

@xiaodonghuan2285 4 года назад

Thanks for your reply. nice post!!!

@AnonAristotel 2 года назад

Awesome.

@GertCuykens 5 лет назад

Can I assume that most return err values in common golang programs end on the heap? Or does err get special treatment?

@foolishway4257 3 года назад

Good question.

@marianzagoruiko 3 года назад

I don't think it does. Allocation only happens if you return a pointer to the variable. In case of error, the value is being returned and not a pointer.

@swibay 2 года назад

@@marianzagoruiko You're right!

@mridulrathod3681 3 года назад

superlike

@mzcustom2 Год назад

I think the point he made at 14:00 could be somewhat misleading as he's emphasizing "moved to the heap right at compile time". The escaped variables still have to be dynamically allocated in heap, so it's complied to call runtime.newobject which calls mallocgc, therefore there's no cost benefit at runtime. Also, I believe this speaker isn't experienced in C programming, not that I'm faulting it, judging by the fact he initially didn't understand why the read function of io.Reader uses a byte slice as its argument instead of an int. That's exactly how read in C works where the caller sends a buf pointer (along with the buf size or less) and gets the number of bytes filled in as the return value, just like all the other functions do unless the argument is a small struct that fits in the registers or a primitive type. From what's known, Golang is a brainchild smart men from Bell Lab who hated C++, so it quite closely follows Unix/C programming style.

@KurtisRader 3 года назад

The question at the end of the talk is interesting. I would have provided a slightly different answer. The primary way to address performance concerns is by picking the appropriate data structures and algorithms. It is almost always a mistake to focus on minutiae; i.e., usually insignificant implementation details.

@baxiry. 3 года назад

usefull

@marianbuciu7853 Год назад

can someone explain 17:55?

@androth1502 5 лет назад

so why can't we just put stuff on the bss segment?

@elio8119 4 года назад

Because Go was created to be simple and not support this kind of intrinsics.

@DagangWei 5 лет назад

17:30 wondering why in the right hand case, it is not `read(&b)` and `func read(b *[]byte)`? in other words, why it doesn't need pointer? (I am new to Golang)

@JacobWalker0814 5 лет назад

The structure of a slice contains a pointer to a backing array of elements. You almost never take the address of the slice itself since it behaves like a pointer already.

@DineshGowda24 4 года назад

Slice will already have a pointer to an array. When you pass a slice to the function, even though the slice will be copied only the underlying address of array will be copied. So any changes on slice will affect the underlying array. So need to pass potiner to slice. Also a slice would look like struct slice{ ptr *[cap]Type, cap int, len int}

@TehKarmalizer 8 месяцев назад

@@DineshGowda24 it really depends on what you are doing with the slice. If there may be side effects that reallocate the underlying array (and therefore the slice), that reallocation will be local inside the function, and the original slice and array will be unaware of the side effects. Maybe that is desirable, but maybe it is not.

@gngn2973 3 года назад

If i understand correctly, for "correctness", you want to try your best to stay off of the heap whenever possible? Great video really cleared some things up for me, being a fairly new programmer.

@TehKarmalizer 8 месяцев назад

No, for correctness, you want the program to perform the intended behavior. And you want it to keep doing so when anyone needs to change the code.

@gngn2973 8 месяцев назад

@@TehKarmalizer yea I've come a long way since that comment lol. Thank you for the response tho =)

@Aditya-ne4lk 3 года назад

fumt

@user-ge8fn4jr5q 4 года назад

wtf is go anyway...

@Jonasmelonas 4 года назад

ok boomer

@TheMrKeksLp 4 года назад

ok zoomer

@yapayzeka 3 года назад

who put the like at 1:05 :D

@johnedissonrodriguezcucanc9131 Год назад

Amazing explanation, I just have any doubt, what is the difference between "&x scapes to heap" and "moved to heap". Thks

@shubhamdhapola5447 Год назад

It's just the matter of how much of the program behaviour the compiler is able to acknowledge. At compile time, the value a variable holds "escapes" to (allocated on) the heap, if the compiler is confident and almost-omniscient of the program's semantics and control flow in the vicinity of variable declaration and usage (like Go, unlike Python). Else if compiler only has partial information, it will allocate an empty memory slot for the variable ahead-of-time and runtime behaviour will unveil that it needs to be "moved" to the heap.