YetiSim Blog

In the original YetiSim state machine implementation, I used polymorphism to represent the various types of nodes that could occur within the state machine. Each possible node type (Start, Final, Error, Join, Fork and State) was derived from a generic Node class. I implemented convenience functions like bool isStart(Node* node) { return dynamic_cast<Start*>(node); } to determine node types to drive the state machine execution algorithms.

I later realized that polymorphism was not required, and that I could implement a single Node class which contained an enum which identified the type of node. This could eliminate the need for calls to dynamic_cast with a relatively small increase in programming complexity. The curious cat that I am, I wondered if this implementation would have better performance than dynamic_cast for large data sets.  I wrote a sample application and timed the dynamic_cast against just looking up with an enum, and found that dynamic_cast indeed was slower.  However, with the -O2 optimization flag passed to gcc dynamic_cast seemed just as efficient.

The question now is whether or not all compilers will optimize dynamic_cast in the same way as gcc.  Could it be that this simple application was easily optimized, whereas a large scale program will show a performance hit with dynamic_cast?  These are questions I’d like to find answers to, however at this point the simple fact of the matter is that dynamic_cast must be executed at runtime to ensure the types are correct, whereas static_cast does not require any runtime overhead.  So, instead of relying upon compiler optimizations, I’ve decided to go ahead with the enum and static_cast solution.