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 RUclips. Awesome, thanks again!
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.
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.
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.
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.
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)
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.
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}
@@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.
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.
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.
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 RUclips. Awesome, thanks again!
I also agree. Clean and short
Clear and smooth, also io.Reader part was nice
It was super nice. Literally an aha moment for me. This was a great talk.
It made me think of similar functions in other garbage collected languages differently as well.
I hadn't understood why the io.Reader interface works the way it does... now I get it, thank you! Excellent talk.
Simply amazing, points are clear and explained throughly, thanks so much.
21:20 Great ending point to great presentation.
This clear why io.Reader is designed the way it is ! Very clear and precise presentation ! Thanks
Really good example about the io.Reader.
That io.Reader example at the end was great!
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.
Can I assume that most return err values in common golang programs end on the heap? Or does err get special treatment?
Good question.
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.
@@marianzagoruiko You're right!
That was super interesting, I've learnt a new thing!
Excellent talk!
can someone explain 17:55?
The best explanation, thank you Jacob !
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.
usefull
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.
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)
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.
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}
@@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.
Amazing explanation, I just have any doubt, what is the difference between "&x scapes to heap" and "moved to heap". Thks
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.
Great explanation!
Amazing explanation
Really nice explanation!!!
He is really good. Thank you!
Cogent. I learned something here.
Thanks for your reply. nice post!!!
This is really good
awesome
wow, I came looking for copper and found gold
Thanks for sharing
Very informative... much appreciated.
so why can't we just put stuff on the bss segment?
Because Go was created to be simple and not support this kind of intrinsics.
Awesome
Awesome.
Best of best
Thank you beer belly Jesus
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.
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.
@@TehKarmalizer yea I've come a long way since that comment lol. Thank you for the response tho =)
superlike
who put the like at 1:05 :D
wtf is go anyway...
ok boomer
ok zoomer
fumt