The measurement problem
Performance work needs more than one kind of evidence. Sampling provides a statistically useful view of where time is spent. Tracing preserves execution sequence and relationships. Function-level instrumentation can expose short call paths and responsiveness problems that averaged measurements can hide.
The approach
I worked on timeline visualization of multithreaded execution and on lower-overhead ways to instrument increasingly dense workloads. One path used compiler-inserted function entry and exit hooks to reconstruct call paths without requiring manual edits throughout the program being measured. Scoped instrumentation complemented that approach where explicit regions were more useful.
For large graphics APIs, I also designed a Clang-based system that parsed API definitions into a structured representation and generated capture instrumentation automatically. The resulting call stream could support replay and higher-level analysis.
What carried forward
The durable pattern is to make the measurement boundary part of the architecture: decide what question each signal answers, minimize observer cost, retain enough structure to explain the result, and separate measurement overhead from workload behavior.
That same discipline applies to performance-sensitive pipelines that cross CPUs, accelerators, firmware, runtimes, and data-conversion stages.