Optimizing components at runtime
Our code should be optimized for the common case. This is a good scaling tactic because as more features and users are added to the mix, it's the common cases that grow, not the edge cases. However, there's always the possibility that we'll have two equally common cases to deal with. Think about deploying our software to a number of customer environments. Over time, as features evolve to meet customer requests, there could be two or three common cases for any given piece of functionality.
If we have two functions that deal with the common case, then we have to figure out which function to use at runtime. These common cases are extremely course-grained. For example, a common case might be "collection is large" or "collection is small". Checking for these conditions isn't expensive. So if we're adaptable to the common case as it changes, our software will be more responsive than if we weren't adaptable to changing conditions. For example, if the collection is...
