Back to C++ Optimization Techniques

Take advantage of STL containers. (See STL container efficiency table). Not only is performance good today, it's only going to get better as STL vendors focus their efforts on optimization and compiler vendors improve template compilation. There are a number of other advantages to using STL:

The STL is not the be-all end-all library of containers and algorithms. You can get better performance by writing your own containers. For instance, by definition, the STL list object must be a doubly-linked list. In cases where a singly-linked list would be fine, you pay a penalty for using the list object. This table shows the difference between Microsoft's (actually Dinkumware's) implementation of lists and SGI's implementation of an STL-compatible singly-linked list called slist.

One other drawback of the STL is that it only provides a limited set of container objects. It does not provide hash tables, for instance. However, there are a number of good extension STL libraries available. SGI distributes an excellent STL implementation with a number of useful containers not defined in the standard.

        
            int x; 
            void Ptr(const int* p) { x += *p; } 
            void Ref(const int& p) { x += p; }

The Ptr function and the Ref function generate exactly the same machine language. The advantages of the Ref function:

• There's no need to check that the reference is not NULL. References are never NULL. (Creating a NULL reference is possible, but difficult).
• References don't require the * dereference operator. Less typing. Cleaner code.
• There's the opportunity for greater efficiency with references. A major challenge for compiler writers is producing high-performance code with pointers. Pointers make it extremely difficult for a compiler to know when different variables refer to the same location, which prevents the compiler from generating the fastest possible code. Since a variable reference points to the same location during its entire life, a C++ compiler can do a better job of optimization than it can with pointer-based code. There's no guarantee that your compiler will do a better job at optimization, but it might.

        
            class OnePhase
                { 
            private: 
                Bitmap m_bMap; // Bitmap is a "one-phase" constructed object
            public: 
                bool Create(int nWidth, int nHeight)
                    { 
                    return (m_bMap.Create(nWidth, nHeight));
                    } 
                int GetWidth() const 
                    { 
                    return (m_bMap.GetWidth()); 
                    }
                }; 
            
            class TwoPhase
                {
            private: 
                Bitmap* m_pbMap; // Ptr lends itself to two-phase construction
            public: 
                TwoPhase() 
                    { 
                    m_pbMap = NULL;
                    } 
                ~TwoPhase()
                    { 
                    delete m_pbMap; 
                    } 
                bool Create(int nWidth, int nHeight)
                    { 
                    if (m_pbMap == NULL)
                        m_pbMap = new Bitmap;
                    return (m_pbMap->Create(nWidth, nHeight));
                    }
                int GetWidth() const
                    { 
                    return (m_pbMap == NULL ? 0 : m_pbMap->GetWidth());
                    } 
                }; 

There are a couple of options. One is avoiding exception handling altogether. As more and more core libraries make use of exceptions, this is getting harder and harder to do, but it is an option nonetheless. Avoiding exceptions means not using try, throw or catch in your code or in library code. Use operator new with the no_throw specification. Turn off exception handling in the compiler itself.

I believe the judicious use of exceptions is the best solution. Limit try blocks to a few key places and make use of the throw() function exception specification to indicate functions that don't throw exceptions. That way the compiler won't add code for unwinding stack objects unless it really needs to.

Runtime type identification allows you to programmatically get information about objects and classes at runtime. For instance, given a pointer to a base class, you can use RTTI to determine exactly which type of class the object really is. The dynamic_cast operator relies on RTTI to perform the proper casting of objects.

In order for RTTI to work, a program must store information about every class with one or more virtual functions. This information is stored in a type_info object. If your project includes many classes, the overhead can make your program larger. Runtime performance is not affected by RTTI.

Very few programs need to use RTTI. Don't use it unless you need it. Simply avoid the dynamic_cast and typeid operators. Make sure that RTTI is disabled on the compiler command line as well.

        
            // C++ stream io
            cout << 'a' << ' ' << 1234 << ' ' << setiosflags(ios::showpoint) 
            << setiosflags(ios::fixed) << 1234.5678 << ' ' << 
            setiosflags(ios::hex) << &i << ' ' << "abcd" << '\n';
            
            // stdio
            printf("%c %d %f %p %s\n", 'a', 1234, 1234.5678, &i, "abcd"); 

As the stream I/O example shows, there's always the possibility that another library will be more efficient. It can pay big dividends to consider alternative libraries, whether they're 3D, graphics, mathematical or I/O libraries. The libraries that came with your compiler are probably not the most efficient code available. Evaluate the possibilities. Benchmark results. Report your findings to the development community at large. And don't forget to wrap and protect your code so that changing low-libraries is as painless as possible.

Back to C++ Optimization Techniques