T w e n t y S i d e d

“Premature optimization is the root of all evil.”

That quote by Donald Knuth gets repeated a lot in programming circles. It dates back to 1974, which means that by the standards of computer science it’s more or less the Code of Hammurabi. While I freely admit that Knuth is a better computer scientist when he’s fast asleep than I am at the peak of a caffeine high, I do have some reservations about this particular bit of wisdom. Specifically: Is premature optimization really that dangerous, and what’s the difference between “premature optimizing” and simply building something properly the first time?

In my professional career, I can’t remember a single instance where premature optimization caused a serious disruption. Maybe that’s a side-effect of the domain I work in. Games have very strict performance requirements that would seem completely unreasonable – bordering on fanatical – to someone working on (say) database administration. The performance of your program is continuously expressed to the user through the framerate of your full-screen application. If a thread stalls, if a frame is dropped, if texture data isn’t fetched in time, if you run out of VRAM, if you oversaturate the memory bus, or if one of a dozen or so other systems falls behind, then it will create problems that a human being can see and feel.

Contrast this with something like a Pixar-style render farm that chugs away rendering gigantic images all day long. Both the game and the Pixar-renderer are rendering images. Time is money so there’s a huge financial incentive to get the Pixar program to run as fast as possible, but if there was a bug that wasted 15% of the available processing power, how long would it take someone to notice? Would they? Meanwhile in a game, dropped or late frames give the user a realtime visualization of your sins. It’s hard for the user to not notice performance problems.

I’ve spent a lot of time in this domain that’s obsessed with performance and maybe a little negligent when it comes to maintaining code, and perhaps that time has blinded me to the wisdom of Knuth’s words, but what’s the actual damage of premature optimization? I get that a programmer might blow a bunch of time squeezing an extra 2% performance out of some system that ultimately doesn’t matter, but aside from the squandered programmer hours I don’t see how it hurts a project. And if we’re worried about wasted programmer hours then we have bigger fish to fry than this. Unreadable code, dependency hell, lack of documentation, failure to abide by best coding practices – all of these have devoured far more of my hours than someone’s mis-spent weekend tinkering with trivial concerns. I can believe that premature optimization is a bad thing, I just can’t get behind the notion that it poses a serious threat to our productivity. At least the premature optimizer is wasting their own time instead of mine.

Continue reading ⟩⟩ “Unity Week #9: Preemptive Premature Optimization”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

Like I said over the weekend, my series on Grand Theft Auto 5 has been delayed. But I can’t bear to leave the Thursday spot blank, so here are some meandering, dashed-off thoughts on the problem of variable naming in C#. To be clear, the problems are mostly with me and not C#. Specifically, switching languages is forcing me to shift my coding standards a little.

For years I worked for a company with a mature (meaning large and resistant to sweeping changes) codebase. In 1993 or so it began as a pure vanilla C project, but sometime around the turn of the century we began migrating to C++ while disrupting the existing code and coding style as little as possible. C and C++ are different languages and the practitioners of each language often have very different ideas about how code should be formatted. Since our codebase was a hybrid, our formatting standards were a slightly strange and anachronistic blend of old and new. Since I used these standards for years, they eventually became part of my personal style. I wasn’t even really a fan of the standards, but after you look at one particular style of formatting for a decade or so, everything else starts to look a little strange.

Let’s look at an example. Earlier in the week I created a SpaceMarine class. Here is how that class might look in C++:

Continue reading ⟩⟩ “Unity Week #8: Some Thoughts on Variable Names”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.