A performance number without its conditions is difficult to use. Ten milliseconds may be excellent or unacceptable; an average can hide the slow requests that matter; a local result may say little about production work. The first task is therefore not selecting a profiler. It is defining the observation.
Start with a question
Frame the work as a comparison that could change a decision. For example: does parsing dominate the time for this input size? Does the new cache reduce repeated reads after warm-up? Does memory return to a stable level after the batch completes?
A good question provides a boundary. It suggests which signal to collect and, just as importantly, which signals can wait. This keeps measurement from becoming a tour of every number a tool can display.
Preserve the conditions
Record the input, software revision, machine conditions, run count, and whether the system was cold or warm. These notes do not need to be elaborate. They need to be sufficient for the next result to mean the same thing.
Run enough times to see the shape of the variation. If the spread is wide, investigate the spread before celebrating a small improvement in the center. Noise is not an inconvenience to average away; it may be the most informative part of the result.
Keep the raw observation beside the conclusion. A result that cannot be reinterpreted later has a short useful life.
Change one thing
Make the smallest change that tests the current explanation, then repeat the same measurement. Large rewrites can improve a number while making it impossible to know why. A narrow change produces knowledge even when it fails.
The final note should state what improved, under which conditions, and what tradeoff was introduced. “Faster” is incomplete. “Reduced the warm-path median while leaving tail latency unchanged” is a result that another decision can build on.