a few unintelligable fixes

Author: tom-harvey

gotime/go-time-66.md

@@ -8,7 +8,7 @@
 
 **Erik St. Martin:** And our special guest today, who I'm really excited about, is Damian Gryski. Most of you may know him because he's always talking about white papers that I know personally I wish I understood enough to read... Before we jump into performance and fuzzing and stuff, do you wanna give people a little background on who you are, for anybody who may not be familiar with you already?
 
-**Damian Gryski:** Okay. My name is Damian, and I've been using Go since before 1.0. I remember things like \[unintelligible 00:01:37.21\] I tweet a lot about Go, I am the moderator of the Go SubReddit, I post a lot of stuff there, too. I like computer science researchy things, so I have a lot of repositories of papers and stuff that I've implemented. I used to live in Amsterdam, working for Booking.com, but now I am in Vancouver, working for Fastly. That's me in 30 seconds.
+**Damian Gryski:** Okay. My name is Damian, and I've been using Go since before 1.0. I remember things like os.Error. I tweet a lot about Go, I am the moderator of the Go SubReddit, I post a lot of stuff there, too. I like computer science researchy things, so I have a lot of repositories of papers and stuff that I've implemented. I used to live in Amsterdam, working for Booking.com, but now I am in Vancouver, working for Fastly. That's me in 30 seconds.
 
 **Brian Ketelsen:** Do we know anybody else that works at Fastly?
 
@@ -74,7 +74,7 @@ So it's really a very small amount of people that actually need to focus 100% on
 
 **Damian Gryski:** And the really good thing about profiling first is that you don't have to worry about other people who are like "Oh, this is where your bottleneck is." You say, "Well, you know what? I'm dumb, I don't know where it is, so I'm gonna profile first." So the people who are too smart to profile - you can just ignore them.
 
-So the whole point is you have to profile because your guesses are always wrong. Modern systems have in general so many interconnected pieces that if you say "Well, I think this is the thing that's slow" maybe you're right - and that's great, \[unintelligible 00:14:33.28\] or maybe you're wrong, and then your profile will tell you where you actually need to speed things up, and then you won't have wasted time on optimizing something that isn't gonna make a difference to the runtime.
+So the whole point is you have to profile because your guesses are always wrong. Modern systems have in general so many interconnected pieces that if you say "Well, I think this is the thing that's slow" maybe you're right - and that's great, your profile will confirm your guess, or maybe you're wrong, and then your profile will tell you where you actually need to speed things up, and then you won't have wasted time on optimizing something that isn't gonna make a difference to the runtime.
 
 **Erik St. Martin:** I think sometimes your guess might be right as to "where", but "why" might be wrong, right? Like, "Oh, well this particular function or section of code is slow", but you think it's actually the instructions, when really it's the GC that it's causing, or things like that.
 
@@ -95,7 +95,7 @@ So your program is doing either something that is not that slow a lot of times,
 
 **Carlisia Pinto:** In your book are you going to list strategies like that, too? Like, which strategies to handle - or even avoid - performance issues?
 
-**Damian Gryski:** Yes... So like I said, the goal at the moment is to take everything that I know about performance optimization and in-general strategies, and then I was gonna go into Go-specific things, like how to use pprof \[unintelligible 00:18:15.04\] and how to write benchmarks and how to read pprof output to know where it is you need to optimize... Stuff around processor-level fixes, so things around cache lines, and padding, and concurrent access -- like, if you have a lot of goroutines, sort of how to speed up accessing the same data structures, maybe branch predictions... So really kind of like low-level stuff that comes in. I was gonna go into garbage collection, minimizing allocations, escape analysis, and those kinds of things. Other things that show up when you profile, so instead of runtime calls, all the interface conversions back and forth, type assertions, defer the balance check elimination... So those kinds of things.
+**Damian Gryski:** Yes... So like I said, the goal at the moment is to take everything that I know about performance optimization and in-general strategies, and then I was gonna go into Go-specific things, like how to use pprof and the different profiles, and how to write benchmarks and how to read pprof output to know where it is you need to optimize... Stuff around processor-level fixes, so things around cache lines, and padding, and concurrent access -- like, if you have a lot of goroutines, sort of how to speed up accessing the same data structures, maybe branch predictions... So really kind of like low-level stuff that comes in. I was gonna go into garbage collection, minimizing allocations, escape analysis, and those kinds of things. Other things that show up when you profile, so instead of runtime calls, all the interface conversions back and forth, type assertions, defer the balance check elimination... So those kinds of things.
 
 I have stuff with unsafe. Unsafe is unsafe, but it can also be fast... Stuff with cgo, some stuff with Assembly, because obviously sometimes that is the way to speed things up, but not always; I have cases where writing something in Assembly has made like a 10x performance improvement. I've had a case where it made zero performance improvement. The code that I wrote was essentially equivalent to what the Go compiler was generating. And I've had cases where my Assembly implementation was slower, because Assembly routines aren't in-lined... So you know, just sort of talking about all those things. At the moment I have the larger performance stuff and outlines for the Go-specific sections... But hey, it's only January, so I have lots of time.
 
@@ -125,11 +125,11 @@ The first section about when to optimize and basic strategies for optimization t
 
 **Erik St. Martin:** Here's a question, too... So one of the things you talked about in the beginning is using data structures and algorithms that are best served for your access patterns and stuff... That's awesome if you have a huge vocabulary of them, right? So how would you recommend people get more familiar with more data structures and algorithms, so that they can kind of have more to choose from? Or do you recommend just kind of going with your first pass being kind of how you imagine it, using kind of standard things that are offered to you by the language and then finding more efficient data structures later?
 
-**Damian Gryski:** I think that really there are only a small handful of data structures that most people need to use on a day-to-day basis, and luckily, for the most part, they're built into Go already. So you know, I have a slice, because I want \[unintelligible 00:23:42.07\] and I need a random access, or I need to be able to iterate things in order, or whatever. Or I have a map, because I have some sort of key-value look-up. And that really should cover almost everything that most devs want to do, and conveniently that's why they're in the language.
+**Damian Gryski:** I think that really there are only a small handful of data structures that most people need to use on a day-to-day basis, and luckily, for the most part, they're built into Go already. So you know, I have a slice, because I want--sort of, you know--order one append and I need a random access, or I need to be able to iterate things in order, or whatever. Or I have a map, because I have some sort of key-value look-up. And that really should cover almost everything that most devs want to do, and conveniently that's why they're in the language.
 
 \[00:24:02.00\] A lot of them that are esoteric data structures have very specific use cases, so you don't need to actually know how to write them, but it's helpful if you know that they exist. I think that's -- how did I learn them? Well, my background is -- I have a computer science degree, and it was from a very theory-heavy university, so I cracked open the books and I did all that work. Does everybody need to do that? No, probably not.
 
-How do you learn more about data structures? Pick one that you're interested in, but really the number that most devs need to know I think is very small. It's nice to know how a binary search tree works; it's nice to understand the guarantees that an AVL tree or a red-black tree give you, versus a regular binary search tree... But if I was actually implementing those, I wouldn't use either an AVL tree or a red-black tree, because they're both a huge pain to implement, because they're really kind of annoying... And a treap gives you basically the same performance and is way easier to implement. So if I needed something that couldn't be solved by a slice or a map and I needed \[unintelligible 00:25:35.04\] that a tree structure will give me, then I would personally go with the treap, because they're just simpler. But you kind of need to know the holes that the data structures that you have don't fill. There's so many data structures out there, so pick some of the main ones and learn those.
+How do you learn more about data structures? Pick one that you're interested in, but really the number that most devs need to know I think is very small. It's nice to know how a binary search tree works; it's nice to understand the guarantees that an AVL tree or a red-black tree give you, versus a regular binary search tree... But if I was actually implementing those, I wouldn't use either an AVL tree or a red-black tree, because they're both a huge pain to implement, because they're really kind of annoying... And a treap gives you basically the same performance and is way easier to implement. So if I needed something that couldn't be solved by a slice or a map and I needed the--sort-of, you know--like log n, in-order guarantees that a tree structure will give me, then I would personally go with the treap, because they're just simpler. But you kind of need to know the holes that the data structures that you have don't fill. There's so many data structures out there, so pick some of the main ones and learn those.
 
 **Erik St. Martin:** So what are some that -- maybe pick like two or three that you think if anybody had to wander off the beaten path might be interesting ones to know. Or your favorites, for people that don't have a list of data structures; what are some favorites or top ones you think people might go to?