There are a lot of benefits to using the Component Object Model. These days, many engines use this approach because of the flexibility it provides. However, that flexibility comes at a cost to performance. The biggest performance costs are calls to new/delete, cache coherency, and virtual methods.

Our M5ObjectManager uses pointers to M5objects which uses an STL vector of pointers to components. This means that as we create Bullets, Asteroids, Raiders, and Planets, we are constantly calling new and delete. These are slow functions and have the chance to fragment our memory. In a later chapter, we will see how object pools can help us solve both of these problems.

However, even with object pools, we still have problems with cache misses. The fact is that iterating over an array of contiguous data is much faster than iterating over an array of pointers to data. When using the Component object Model, the CPU will be spending a lot more time chasing pointers and loading that data into the cache than if we just used arrays. Unfortunately, this is the price we pay for flexibility. Depending on the game, this may or may not cause a problem.

Virtual methods are also a source of potential performance problems because the function to call must always be looked up at runtime and they cannot be inlined by the compiler. Again, this is the price we pay for flexibility. We have an approach that allows our designer to load a behavior from a file and change that behavior at runtime. In my opinion, that outweighs the performance issues, at least at the beginning of the development cycle.

You may have heard premature optimization is the root of all evil. It is more important to focus on making a fun game and to solve the performance problems later. You always have the option of hardcoding specific behaviors or data in the game object much later in the development cycle. If possible, you might merge two or more components that always get used together once you are in the polish stage. However, by limiting your flexibility early on, you may never discover a fun feature that comes from mixing two components in a way that wasn't originally planned.

My advice is to focus first on algorithmic optimizations, then macro optimizations, then finally micro optimizations. What I mean is that it is better to worry about the time complexity of your physics engine and how many draw calls or collision tests you are performing, before worrying about what is in the CPU cache or the performance cost of virtual functions. While they can be a problem, these things fall under the category of micro optimizations.

However, before starting the long process of creating a game using an unfamiliar game engine, it can be a good idea to do some simple prototype tests to make sure the engine can meet the needs of the game. For example, a programmer could approximate the number of objects, and components, and test for performance to see whether the engine will work.