I hear this less today but I still hear it every once in a while and I'm shocked when I do because it was nonsense, even in the late nineties.
In terms of performance, it didn't matter, then, and it doesn't matter, now. I'm only addressing it because a belief that discourages the usage of virtual methods is a dangerous one which must be disabused.
Just scratching the surface of this argument, you can see its absurdity.
An indirect call is going to take a constant amount of time. You look up where to go and go there. Its worst-case time is its best-case time. A conditional tree's worst-case cost is going to grow with the number of cases.
As complexity grows, the average cost of a virtual method call is going to look better and better. So, except for areas of very small complexity, the argument that a virtual method call is slower just doesn't stand up to the barest of scrutiny.
Your choices are as follows:
- There's a constant number of choices and you're optimizing the constant-multiplier of your software - literally the last thing you should be considering.
- There's a flexible number of choices and you're choosing between a constant cost or a cost that can be optimized to be logarithmic with the number of choices.
Either way, the virtual method call comes out smelling like a rose.
That is, of course, notwithstanding the fact that there's no point at all in worrying about this kind of cost until there is some evidence you should be expending mental energy on such trivia, which was even true in the late nineties.