How can you reliably diagnose C++ performance issues using measurements?

Assuming the objective is to locate performance bottlenecks in a C++ application, the process often relies on collecting runtime measurements such as CPU cycles, cache misses, or wall‑clock time.

However, uncertainties arise from measurement overhead, platform‑specific counters, and the influence of compiler optimizations, which can mask or distort the true cost of code paths.

Given these constraints, what strategies can minimize measurement intrusion while still providing sufficient resolution?

How should one select and combine different profiling tools or hardware counters to cross‑validate results?

When measurements show conflicting signals, what criteria help decide whether a observed slowdown is genuine or an artifact of the measurement method?