Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Efficiency Concerns
I have to admit that efficiency is not something to which I give tremendous thought. If I were doing some kind of real-time processing, it would be an issue. If I were doing analysis of some huge amount of data, such as a web server log, or if I were doing some computationally intensive number crunching in a science or engineering environment, it would likewise be an issue.
For most everyday applications, it is not worth shaving off a few milliseconds here and there. Processors are thousands of times faster than they were 30 years ago, and we don't have to worry about it as much as we used to.
But I have already said that a good interface is important. And sometimes efficiency is an interface concern because a function call might take a measurable amount of time to return and/or it might be called thousands or millions of times in a loop. So I'll make a few remarks on performance here.
First, I'll repeat myself: In many applications, speed is not a concern. In these cases, code structure and readability are more important. I don't advocate inefficient code, but be aware that optimizing code for speed frequently decreases its readability. Be sure the tradeoff is worth it.
Second, don't optimize too early. As readability decreases, you will hurt your own productivity. Furthermore, you don't want to optimize until the code is reasonably stable. As the adage says, "Make it work; then make it fast."
Third (and it is hard to emphasize this enough), do not rely on your intuition. Programmers tend to be bad at making guesses at where the slow code is. The literature abounds with anecdotes of developers who have made assumptions that were "obviously correct," but were actually drastically wrong. There are profilers and other performance tools out there, probably even packaged with your compiler. Always use a profiler before optimizing.
There are a few common-sense actions we can take in C++ to optimize our code. The most important is the selection of good algorithms and their corresponding data structures. If you use something from the standard template library, its performance will probably be good. If you suspect that it isn't, measure it and see if you can improve on it by writing your own special-purpose replacement.
If a method is called repeatedly (thousands or millions of times), make it an inline function to save the overhead of the stack manipulation. Methods declared in the class body are inline code by default.
Object creation carries an overhead with it. Do it outside a loop if you can. Likewise, any time-intensive code that can be easily moved outside a loop should be moved. Intermediate results can be cached instead of recalculated, and so on.
I/O is slow, especially disk access and networking. There's not much to do about it except to code carefully. Buffering can help, as can nonblocking I/O techniques.
If there were ever a time and place for laziness and procrastination in software engineering, performance optimization is it. Optimize only as much as you need to, and put it off as long as possible.