I used to work at a place called Rogue Wave Software.
It was my first real job and a fantastic place to cut my teeth. Even though it was the '90's, the developers there had a better concept of what software design was than a lot of the developers I've met, since.
One little story that still amuses me to this day involves one of their products, DBTools.h++ (later SourcePro DB). DBTools.h++ had a very object-oriented design. Even today, that would be true but it was especially true at the time.
This anecdote is about how that design held up to other approaches with regards to performance.
In the 1990's, there was a prevalent misconception that biased some people away from object-oriented designs. Hilariously, this extended to code that connected to a database across a network.
Remember, networks, then were very slow compared to modern networking. Computers were slower, too, but I think networking was a more infantile technology and thus has come a lot further in the last twenty years.
As a result, one of the sales problems they had was convincing people who were accustomed to coding to a C-level API that they would not take a performance hit by using the DBTools.h++ library.
Thankfully, the client-side documentation for the various databases all shared a common example right in the beginning. It was kind of the "Hello, World!" of the 20th-century database client space.
Rogue Wave's solution to this sales problem was, in my opinion, quite elegant. They simply converted the example over to one that used their library.
Detractors would say "This just shows that you abstract away the client API. We already knew that. What about performance?"
Then the salesman would show them the performance data. The code that the database companies were shipping in their documentation as their best foot forward - the way to use their system - was not as fast as this object-oriented system with several layers of abstraction and much-reviled virtual method calls.
The reason the Rogue Wave solution was so much faster was precisely because it was object-oriented. Having the layers of abstraction available to the developers of that class library hid the little problems on which people so often dwell and exposed the big ones people rarely even see.
There's an important lesson, here: You can't make every optimization that's possible. Performance-tuning is not about the optimizations you theoretically could make. It's about the optimizations you actually do make.
