I am a huge fan of DRY (don’t repeat yourself). It has the obvious perk of making code easier to read and comprehend. There are also other benefits that are less obvious.
Most people apply this principle to code for decomposition and overlook the actual data being stored. However, this should not be the case! Performance can suffer greatly when we aren’t diligent in making our data as DRY as possible.
When dealing with software where objects have a long lifetime the cost of construction gets ammortized to the point of non-existenince. However, for short lived objects the construction/destruction my consume the majority of the objects lifecycle. For these types of objects keeping things DRY is very important. I’ll discuss a case where DRYing out an object has very real performance consequences.
One example, would be using an object as identifiers for data objects. Take the following code as an example:
CBaseState *statePtr = NULL; // CBaseState is the base class for all state variables statePtr = stateList[0]; // stateList is a std::vector// every CBaseState has an ID field of type CBaseID, this is used to ID different states at runtime // CPositionXID is derived from CBaseID if (statePtr->GetID() == CPositionXID()) { printf("We have a XPosition state\n"); }
The class CBaseID is defined as:
class CBaseID
{
StateEnum StateType;
int ID[8];
std::string IDString;
}
The equality operator checks the StateType and ID fields for equality. The IDString is a textual representation of the StateType and ID array. The IDString member is only used for display purposes in the debugger, and never referenced in the program.
The program creates 380,000,000+ instances of CBaseID derived classes during a typical processing run. Due to the creation of IDString the std::string constructor/destructor consumes 12% of the processing time! A simple change to DRY out the class yielded a 12% reduction in run-time.
The take away, don’t repeat data unnecessarily! If you can say something using one declaration, don’t use two. Make your tools work smarter, not harder.
