Transcript from the "Scoping and Prototypes" Lesson
[00:00:21] Let’s go back to our good friend benchmark. I’m gonna make a little test function just cuz there’s a lot of stuff happening. We’ll have our test function, all right, neat. We’ll say like it'll take a point and it'll add its x and its y, I don't know. point.x + point.y, and we'll go ahead, make that x and y, so this.x = x.
[00:01:08] This.y = y, very cool. And then in this function, we'll make a new point.
>> Steve: And we'll add the x and y at the point. All right, make an object, it's got an x and y, create one of them. We'll add them together.
>> Steve: So we'll go in here.
[00:01:41] And we'll just say, call that test function every time. I don't wanna measure me making the whole thing. I'm just gonna run it in the exercise part. And not to ruin the surprise, but I'm gonna turn this number down a little bit.
>> Steve: 800 milliseconds, that seems like quite a bit considering I had that much larger iteration for just adding 2 things, and it was 47.
[00:02:18] I think this would go for about eight seconds, if I let it really go for it. That seems unacceptable. And it’s like weird to me, right? How is this that much different? I don’t know. I’ve measured. I know that it’s bad. I’m just gonna move some code around.
[00:02:36] Don’t mind me. Let's go ahead and put this up here, right? I don't need to define the class in every iteration.
>> Steve: Nine milliseconds, [LAUGH] that's a wee bit faster. Okay, now one would argue, well, you are creating a class in every run. I don't think that's what got me from 9 milliseconds to 800, right?
[00:03:05] It seems like there might be something else going on here. And so I have some suspicions. So what I'm gonna do is I'm gonna just try one more thing. Remember when I was comparing all those types? I wanna try one other thing. I'm gonna go ahead and I'm gonna grab this point and bring it back to the classes one.
[00:03:28] I'm gonna do some science here. I had it already, that's great. So in the other case, I was making one of these inside the test function, and the other one I had it up a scope. I had it the same point class, I wasn't rewriting it all the time.
[00:03:45] So I've run this code, I know that these are the same type. What if I had a,
>> Steve: We'll return a new point.
>> Steve: And we'll say make a point.
>> Steve: And we'll say make a point.
>> Steve: And we'll see if they have the same map.
>> Steve: They don't, but they were made from the same infrastructure that worked last time, right?
[00:04:29] We saw it. I'm not losing it, right? We saw that when I used the point class last time that they were the same. And now I'm doing it inside this function and they're different. Also, it's way slower. Like 9 milliseconds versus 800. Any guesses? When we make the point inside of a function, it's not parsing, theoretically.
[00:04:54] We are doing it every time, that is true. But it's not the parsing making the big difference. We're making this class as a different prototype chain every time, right, which means that each one of these points that come out of here points to a different prototype object. We're making a fresh point function every time, so on and so forth.
[00:05:12] And we can see that this little, tiny difference in where I've put that code clearly had dramatic effects on how slow my code was. 9 milliseconds, 800 milliseconds, right? Now, does this mean that during lunch today we go through our code bases and we look for every time I've got a class inside another function?
[00:05:31] No, but it does notice you open up your web application while it's running in production mode. You go later and see, you run the performance thing, you're like, wow, that's taking a really long time, right? Then, you begin to spelunk in there. And at least you can have some hypotheses about how this stuff actually works, so that you're not just throwing stuff at the wall, right?
[00:05:50] I know that if I'm making stuff inside of a function it can have a different chain, I know if they went through different paths to get to the same object, that can be the problem, right? Do not speculatively go through your code base and do this everywhere. But I'm like, this is taking too long to load.
[00:06:06] Or like I see the little red triangle there. Or I see that I'm pegging the CPU or something along those lines. Now, yes, we have some hypotheses on what's happening here, right? We haven't even touched the browser land yet, which can have a whole bunch of other implications.
[00:07:06] So what does that really mean for us? If you can have a function that creates the object, rather than you doing it by hand every time, if you're always making a object literal, yes, you could type the curly braces and the properties, right? But if you know if you're using a lot, it might make sense to make a function that gives you a consistent object that was created the same way every time.
[00:07:24] And that way, you don't have to think about this. Every moment you're thinking about all the stuff that we just kinda talked about, it's like you probably have some changes you need to make in the architecture of your code. And try not to modify them after the fact.
[00:07:38] Maybe it makes sense to make a new object that gets created the same way. Cuz that will have the same map as all the other objects made that way. But probably the real easy way to do this is we all get really happy about TypeScript or Flow and like, yeah, I'm gonna do it.
[00:08:15] So most of the answers here are either measure and see what's happening and, hopefully, you're a little bit better at making hypotheses now. Or, b, the point I'm gonna end with at the end of the day is, be great if we could just have tools do this stuff for us, right?
[00:08:27] That is ultimately the right answer.