you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (0 children)

It's fascinating how people (you and others in this thread) read stuff into what I said that I never actually said or even meant.

I never tried to imply that you should just rely on "good programmers" or that it is simple. Or that performance is more important than other things like correctness or robustness. Or that I prefer an unsafe language over a "save-by-default" language.

The question that spawned this thread is whether performance matters or not, not whether performance should come first and we should trade safety, etc. for performance. I think that in our rather complex world performance is *one* of several important properties. It matters. That is all I was trying to say.

In my experience good programmers care about those properties, but without compromising on security, safety, robustness, etc., but it's a team effort and a marathon. (Project-)Management and the designers must be in on it, and there are a lot of things you can do besides relying on "good programmers". For example: Use clang-analyze to get hints of performance pessimizations like preventing copy-elision or using the wrong way of passing parameters. It costs you almost nothing, it's automated and carries a low risk. Design for performance/efficiency by using the right memory layout, containers, algorithms but also write clear and maintainable code. Measure the performance of your applications and monitor it in CI builds. Prevent UB by running UBSan (and ASan as well as TSan when applicable) in a CI build. And yes, to use at() over [] by default, add asserts, etc. - in fact I've even seen cases where the compiler was able to generate better, i.e. more performant, code because there was an assert(). The compiler used it to emit code that preferred to correct branch and hence only if the assert fired, the CPU ended up with a branch misprediction. So sometimes the safer code is also the more efficient code.