Code Written for Performance

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas Crockford: So I need to say something about performance, because I sometimes hear the need for performance as the excuse for why we can't have good style. It turns out those arguments are all wrong. Performance specific code is usually crufty because we're removing generality from the code. We're increasing paths through the code, which makes testing and maintenance all much harder to do.

[00:00:28]
Clean code is much easier to reason about. So we should try to keep our code as clean as we can, for as long as we can. Donald Knuth of Stanford said that premature optimization is the root of all evil, which is true. We should not attempt to optimize any code until we have measured it.

[00:00:45]
We should then do the optimization, we should then measure again. And if we did not get a significant improvement, then we should consider the change to be a bug and back it out. If the reason we added cruft to the code base was to make it faster, if we didn't actually obtain the significant performance increase, then it fails, and we should remove that code.

[00:01:07]
So measure twice, cut once. It turns out most code has a negligible impact on performance, so we should only bother with optimizing the code that is taking the most time. You have only a limited amount of time for doing optimization, so you don't wanna waste that time optimizing code that doesn't matter.

[00:01:26]
You need to optimize your optimizing. And finally, algorithm replacement is vastly more effective than code fiddling. So if your code is slow because you've got an n squared loop, fiddling with the details of the inner loop will have no effect on significantly increasing n. The only thing that could work is replacing that code with a different algorithm in maybe an n log n algorithm, which can then get you a much larger n.

[00:01:54]
And that kind of change is much easier to do if the code has not already been pre-optimized. Programming is the most complicated thing that humans do. Computer programs must be perfect and humans are not good at perfect, especially me. I am a deeply flawed human being, but I'm a pretty good programmer, but it requires a tremendous amount of effort and discipline.

[00:02:19]
So designing a programming style demands discipline. It is not selecting features because they are liked or pretty or familiar. It's because it helps you to reduce your error rate. The alternative is spending more time in the abyss. You know what I'm talking about. That's that cold, dark, hurtful place we descend into where we go and battle the demons and kill the bugs.

[00:02:45]
When I first started programming, it was wonderful. I was having this epiphany. I thought I had this new way of understanding everything in the world, and I thought it was great. I thought everybody should learn how to do this, cuz this is really exciting stuff. I don't believe that anymore.

[00:03:02]
I think that we are able to do programming because there's something seriously wrong with us.
>> [LAUGH]
>> Douglas Crockford: Normal people can't do this. If a normal person goes down into the abyss, they come right back up and say, I'm changing majors. I don't know what's wrong with you people.

[00:03:18]
I'm out of here. We're able to do this because of this amnesia thing that we suffer from, that we forget how much time we spend down there and how awful it is when we're down there. And that's what allows us to go down there again. Also, we're tremendous optimists, that we think that we can actually go down there and win and come back, and that's a great thing.

[00:03:43]
I don't think you can be an optimist and be a programmer. Or you gotta be an optimist to be a programmer, it's just necessary. That's also why we can't schedule worth crap, right? How long is that gonna take? And go well, it's about that many keystrokes, so [SOUND] it is should take about that long.

[00:03:57]
We forget about that, right? That's where most of the time goes. So if you want to be more effective, more productive, figuring out a way to stay out of there, that's the big win. Figuring out how to reduce your keystrokes is irrelevant, right? You wanna optimize the thing that's taking your time.

[00:04:12]
And the thing that's taking your time isn't the typing, it's that. So the JSLint style was driven by the need to automatically detect defects. And that forms that can hide defects are considered defective. Even if they're not bugs that instant. So when I was developing JSLint, there was a thing called comped out lang.javascript on the Usenet.

[00:04:36]
And there was an endless stream of people saying, my program doesn't work. Can someone tell me why? And so I would take them and I'd throw them in JSLint, and sometimes it'd go, there it is. And sometimes it'd go, it couldn't, why is that? And sometimes it was because they were using forms which made further analysis of the program impossible.

[00:04:55]
And eventually, reluctantly, I came to decide that, if you're writing that way and you don't need to, then that's a problem, because we want to make our programs make the errors stand out. And you can do that by writing better all the time. So the idea of sub-setting a language is not an original idea, that for virtually every language you wanna subset it.

[00:05:29]
It's been said only a madman would use all of C++. It's also been said only a madman would use C++, but that's a for another time. And there is something nice about having everybody using the same subset. Every team writing C++ will figure out how much of the language they want to use.

[00:05:49]
And that's fine until they now have to take over someone else's code and go, friends, crap, you don't have to deal with that stuff. So if we could get everybody using the same subset, that makes interoperability a lot easier.
>> Douglas Crockford: So there will be bugs. I'm not promising that you can be bug free if you adopt a better programming style, but you can move the odds to your favor and you definitely win, and you do that at no cost.