As Meyers noted in Item 24 of Effective C++,the inability to inline a virtual function is its biggest performace penalty.
Virtual functions seems to inflict a performace cost in several ways:
[1] The vptr must be initialized in the constructor.
[2] A virtual function is invoked via pointer indirection. We must fetch the pointer to the function table and then access the correct function offset.
[3] Inlining is a compile-time decision. The compiler cannot inline virtual functions whose resolution takes place at run-time.
The true cost of virtual functions then boils down to the third item only.
-------------------------------------------------------------------------------------------
Virtual function calls that can be resolved only at rum-time will inhibit inling. At times, that may pose a performace problem that we must solve. Dynamic binding of a function call is a consequence of inheritance. One way to eliminate dyanamic binding is to replace inheritance with a template-based design. Templates are more performance-friendly in the sense that they push the resolution step from run-time to compile-time. Compile-time, as far as we are concerned, is free.
The desing space for inheritance and templates has some overlap. We will discuss one such example.
Suppose you wanted to develop a thread-safe string class that may be manipulated safely by concurrent threads in a Win32 environment. In that environment you have a choice of multiple synchronization schemes such ascriticalsection, mutex, and semanphores, just to name a few. You would like your thread-safe string to offer the flexibility to use any of those schemes, and at different times you may have a reason to prefer one scheme over another. Inheritance would be a reasonable choice to capture the commonality among synchronization mechanisms.
The Locker abstract base class will declare the common interface:
1
class
Locker
2
{
3
public
:
4
Locker()
{ }
5
virtual
~
Locker()
{ }
6
virtual
void
lock
()
=
0
;
7
virtual
void
unlock()
=
0
;
8
}
;
9
10
class
CriticalSectionLock :
public
Locker
11
{
12
13
}
;
14
class
MutexLock :
public
Locker
15
{
16
17
}
;
Because you prefer not to re-invent the wheel, you made the choice to derive the thread-safe string from the existing standard string. The remaining design choices are:
[1]
Hard coding. You could derive three distinct classes from string::CriticalSectionString, MutexString, and SemaphoreString, each class implementing its implied synchronization mechanism.
[2]
Inheritance. You could derive a single ThreadSafeString class that contains a pointer to a Locker object. Use polynorphism to select the particular synchronization mechanism at run-time.
[3]
Templates. Create a template-based string class parameterized by the Locker type.
////////////////////////////////////////////////////////////////////////////////////////////
Here we only talk about the Template implementation.
The templates-based design combines the best of both worlds-reuse and efficiency. The ThreadSafeString is implemented as a template parameterized by the Locker template argument:
1template <class LOCKER>
2class ThreadSafeString : public string
3{
4public:
5 ThreadSafeString(const char* s)
6 : string(s) { }
7
8 int length();
9private:
10 LOCKER lock;
11};
12 The length method implementation is similar to the previous ones:
1template <class LOCKER>
2inline
3int ThreadSafeString<LOCKER> :: length()
4
{
5 lock.lock();
6 int len = string::length();
7 lock.unlock();
8
9 return len;
10} If you want critical section protection, you will instantiate the template with a CriticalSectionLock:
{
ThreadSafeString<CriticalSectionLock> csString = "Hello";
...
}
or you may go with a mutex:
{
ThreadSafeString<MutexLock> mtxString = "Hello";
...
}
This design also provides a relief from the virtual function calls to lock() and unlock(). The declaration of a
ThreadSafeString selects a particular type of synchronization upon template instantiation time. Just like hard coding, this enables the compiler to resolve the virtual calls and inline them.
As you can see, templates can make a positive performace contribution by pushing computations out of the excution-time and into compile-time, enabling inling in the process.