Optimize the slowest thing

Yesterday I was writing the back cover copy for The C# Programming Language, Third Edition. As a bonus, I got to read the book in draft form. This is a great book, even better than the previous editions because it’s annotated. I’m not sure when it’ll be available, but you can pre-order it from Amazon.

Disclosure: I used to be Series Editor for the Microsoft .NET Development Series, so you’ll find my name in previous editions of this book. I’m not doing that any more, although I do still take on occasional writing, editing, and reviewing work for those folks.

One of the annotations struck me, and I’d like to share a little bit of it with you. (I’ll try to stay within the limits of Fair Use.) It’s by Eric Lippert, and it annotates a section of the specification that talks about the instantiation overhead of classes and structs:

Always remember that it makes little sense to optimize anything other than the slowest thing. If your program is not gated on heap allocations in the first place then spending any time deciding whether to use structs or classes for performance reasons is not an effective use of time. Find the slowest thing, and then optimize that.

Find the slowest thing, and then optimize that. Great advice. It reminds me of the chemical principle of the rate-limiting step. It’s also something that’s easy to forget when you’re designing a program that you want to run fast. Don’t try to optimize it before you write it. First make it run correctly, then make it run fast.

You can find another take on this, possibly a bit extreme, over at Tim Bray’s WideFinder 2 project. The latest posting on that is here.