Amdahl’s Law

[00:00:00]
>> Really I just wanted to talk to you about one last thing called Amdahl's law, which is a super, super quick thing. And it's even funny that it's a law or it has a name because it's so obvious, it just hurts. Which is that, imagine you have an application, right?

[00:00:14]
And you have some piece of code that's hot that you wanna optimize, right? But that piece of code only is 5% of the time, so if you make it amazing ten times faster, right? Which means instead of 5%, now it is half a percent, so you saved four and a half percent and now your code is four and a half percent faster, right?

[00:00:34]
So this thing talks about is that, you can get amazing performance improvements over small code, but it really matters how it is in the big picture, right? And if the big picture of that code isn't used very often, then you're not gonna see a huge performance improvement overall, right?

[00:00:52]
So for example, we talked about how JSX could be like orders of magnitude faster in terms of running and doing stuff. And it's true, but overall that piece of code represents maybe 2, 3, 4% of the overall execution of the application, right? So even if you can make that zero, overall you've only improved the application speed by a couple of percentage points, and so that may not be worth the work that you need.

[00:01:18]
Anyways, Amdahl's law is mostly used in kind of the hardware design, etc., but I think it's appropriate here. And I kind of just wanted to put things in perspective that like, hey, don't just go optimizing everything all the time crazy, right? Because fundamentally, you write code for yourself first.

[00:01:35]
It's only secondary and incidental for the computer. The computer can execute the craziest, ugliest code you have, just as fine, it does not get a headache. I will get a headache trying to read the crazy code, right? So we write code for us first, make it pretty so that future self will thank you.

[00:01:52]
The fact that sometimes we come across code that really needs to be optimized and these tricks matter, then yeah, sure, we can do that. And sometimes, for example, some things are just good idea, like using triple equals over double equals, it's hard to argue that using double equals is better, right?

[00:02:09]
So just use it cuz it's just easier. It doesn't make it any harder to read what's going on or understand etc. I can also make a pretty good argument that like, hey, initialize all of your properties at the beginning because it just makes it easier to understand what's happening in your code.

[00:02:24]
And it just so also happens to make the code run faster because the inline caches and hidden classes that we talked about, etc., right? So I would say, primarily, do these things because they're a good idea for you as a human and only later do them for the computer.

[00:02:39]
Most things I've shown you were really, I wanted to show you not necessarily tricks to kind of hack the system, but more I wanted to show you how the system works. How the machine underneath and the virtual machine on the top, how they talk to each other and how they create this illusion of having JavaScript.

[00:02:57]
Because it is an illusion, right? At end of the day. It doesn't exist, the hardware doesn't know how to execute JavaScript. And so we go through these layers of trickery that we create this illusion that we have JavaScript for us, running inside of the modern CPU.