Pre-state the expected effect before timing a micro-optimisation, so 'no difference' is an expected outcome

Before timing an optimisation that cuts data traffic (e.g. sending only changed values instead of full snapshots), estimate the largest CPU effect it could have and write it in the plan:

expected saving ≈ (share of the overhead spent on the traffic you're cutting) × (fraction of that traffic removed)

You can get the share from a no-encode or no-output arm (full vs reduced traffic with everything else off) and the fraction from byte counters. If the product is under your noise floor (a few percent), say up front that 'no difference detected' is the expected result. Then: - add one constructed best-case workload where the effect should be large, labelled as such, alongside the realistic one; - keep the arms being compared in the same executable, toggled at run time, so layout effects don't confound a small difference; - collect the traffic counters over the whole timed run, so the CPU result can be tied to a measured byte reduction rather than a short sample. This avoids both over-reading noise as a win and abandoning a real but small improvement.