(TUTORIAL) C++ Programming
Virtual functions
I have heard people say things like ``As a performance optimization, I've removed all virtual functions and replaced the virtual function calls with switch statements and ordinary member function calls.'' That is a major performance killer. If you need the functionality that a virtual function call gives you, there is just no way to do it faster than through a virtual function call. The switch switch/call construct is guaranteed to require at least as many instructions (probably more) and is an instruction pipeline killer for the CPU, something that the virtual function call interestingly is not.
Inline functions
While well chosen inline functions may speed up your program, ill chosen ones will lead to bloated executables, and are likely to reduce the number of cache hits since active code areas will increase in size. Remember that an inline function is actually not a function, strictly speaking. If inlined, the instructions for the function will be inserted at the place of the call. If the function is large (more than a very few instructions) the size of your program will grow considerably if the function is called often. More interesting is what happens if the compiler for one reason or another fails to inline it. It will then have to make an out-of-line function for it, which will be called like normal functions. There is one difference however (getting into the area of technical problems here, I will return to this one shortly.) Where will the out-of-line function reside? With one exception, all compilers I know of will add one copy, as a static function, for every translation unit (read .cpp file) where the function inlining failed. In a large program, this might mean *many* copies, and since every copy is in its own memory area, you will not get the boost from high performance hits due to good locality either.
Fear of template code bloat
It is a well known fact'' that templates leads to code bloat, many programmers avoid them. This means rolling their own algorithms and collections instead of using standard ones. Unless, however, the programmer is a top-notch algorithm and data-structure guru, the result is just about guaranteed to be slower, and quite possibly larger, than those in the standard library. After all, the contents of the standard library are state of the art. Have a look at the SGI STL, and read the documentation and code commens, and you will notice that many of the data structures and algorithms used were not even known a year ago. How many programmers have a working knowledge of the latest and greatest of algorithms and data structures?
Technical problems
The largest technical reason for slow C++ programs is compilers with very poor code optimizers. Most C++ compilers use exactly the same optimization techniques as C and Fortran compilers do, despite the fact that the way a C++ program works and accesses memory etc. differs a lot. I know of one C++ compiler that has a code optimizer made especially for the requirements of C++. It has been shown to equal and even beat Fortran for performance, and that is when using good encapsulation and templates. When feeding it a program written like a C program, performance will be poorer. If you are curious,(Note. I am not associated with them in any way. I have used their compiler, that is all.) Unfortunately it is not available for OS/2, and I doubt it ever will be (bug them about it, though, and it might happen.)
COURTESY: www.edm2.com
