A Good Attitude About Efficiency

Bill Venners: The C++ community is very efficiency minded.
Could you give programmers your idea of what is a healthy attitude towards efficiency?
Performance is very important, but so are easy-to-understand designs. How do you decide
when to mutate a design and make it more confusing or harder to maintain—or whatever
the tradeoff may be—to make it faster?

Scott Meyers: I have a two-pronged approach to efficiency. First,
when you're designing the application, you have to consider efficiency. I'm assuming that
you, as the designer, are designing something you know something about. You must
make some educated guesses about where you think performance bottlenecks will and
will not exist. That means efficiency might appear early in the design, just because you
know certain things about the application in general. I don't think it's inappropriate to
keep efficiency in mind when you design. You don't want to design something that will
be inherently inefficient.

The first prong of my two-pronged approach, then, is to keep efficiency in mind from
the beginning. Don't completely ignore efficiency up front in favor of fine tuning later.
You shouldn't bend over backwards for efficiency up front. Design so things will be
efficient enough most of the time. Shoot for clear, straightforward, and
maintainable code, but try to avoid introducing gratuitous inefficiencies.

The second prong is fine tune later with profiling. If you find some bottlenecks in the
program by running it and profiling, then go back and rewrite the presumably localized
parts of the code to improve efficiency.

Serious efficiency problems arise when people design systems with the attitude that,
"We're just going to worry about correctness first. We won't even think about efficiency
until later." The results have been pretty disastrous.

This is language-independent advice. No matter what language you program in, you
should never design something that you know just by looking at it that it won't be
efficient enough.