More effective C + + efficiency

I suspect some people are doing secret Pavlov experiments on C + + software developers, or why many programmers drool when it comes to the word "efficiency." (Scott Meyers is really humorous translator note)

In fact, efficiency is not a matter of joking. A program that is too big or too slow their merits, however compelling, are not acceptable to people. It's supposed to be like this. Software is used to help us better work, said that the slow speed is better, that the need for 32MB of memory program than just need 16MB memory program is good, said the use of 100MB disk space program than only occupy 50MB disk space program is good, this is nonsense. And while there are programs that take up more time and space for more complex operations, for many programs, they can only be blamed for poor design and sloppy programming.

Before you write an efficient program in C + +, you must realize that C + + itself is absolutely irrelevant to any performance problems you encounter. If you want to write an efficient C + + program, you must first write an efficient program. Too many developers ignore this simple truth. Yes, loops can be manually expanded, and shift operations (shift operation) can replace multiplication, but if you're using a high-level algorithm that's inherently inefficient, these tweaks won't work. Do you still use the two-time equation algorithm when the linear algorithm is available? Do you compute duplicate values over and over again? If so, it's no exaggeration to liken your program to a second-rate tourist attraction, which is worth taking a look at if you have extra time.

The contents of this chapter illustrate the issue of efficiency from two perspectives. The first is to focus on what you can use in any language from the perspective of language independence. C + + provides them with a particularly attractive implementation path, because it supports encapsulation very well, thus enabling better algorithms and data structures to replace inefficient class implementations, while interfaces can remain unchanged.

The second is to focus on the C + + language itself. High-performance algorithms and data structures, although very good, but if the actual programming in the code is very rough, the efficiency will be considerably reduced. The most potentially dangerous mistake is one that is both easy to make and not easy to detect, and it is a mistake to construct and release a large number of objects. Excessive object construction and object release are like a massive haemorrhage in your program's performance, and precious time flows away every time you build and release unwanted objects. This problem is common in C + + programs, and I'll use four terms to explain where these objects come from and how to eliminate them without affecting the correctness of the program code.