The other day, leader of a “star studded” GitHub repo sent me email with this paragraph:
“… This is hard. I am in the process of re-engineering XYZ’s deeper work in stage 2. He “went away” and did a lot of refactoring, and we end up losing massively on the
performance side of things….”
My comment. Standard C++ code can be very fast, but there are few fundamental “laws of physics” that can not be broken that must be applied to the fast, mission critical code.
The minimal set:
1. do not include
2. do not
3. minimize the use of
4. Favor core language features over
5. C++17 features, make for smaller/faster code vs 11/14
6. C++ ABI problem is not solved.
Applying the above correctly to the existing code can not bring performance penalties. Just benefits.
Applying the above to existing code is hard. Especially if you have believed (strongly) the opposites “rules” are true.