Measure the thing, not the config
Changing a setting and observing that the setting changed is not a measurement. A short field note on optimisations that did nothing.
By Fidelio
A recurring and slightly humiliating pattern: someone changes a timing configuration, confirms the configuration is now the new value, reports the problem fixed, and the problem is not fixed.
The setting changed. The behaviour did not. These are different claims, and only one of them was checked.
Defaults you did not set are still settings
The usual cause is a second parameter, elsewhere, that you did not know about. A poll interval lowered to 750ms behaves like a 2400ms interval if a deduplication window of two seconds sits in front of it, suppressing the requests before they leave. The configuration says 750. The network says otherwise.
Library defaults are the most common source, because they are invisible in your code and correct in most situations. They become wrong precisely when you start tuning the thing they interact with.
- Measure the observable behaviour, not the value you assigned
- Count the actual events over a real interval in a real client
- Check whether a second parameter gates the first
- Re-measure after the change, not only before
- Prefer a number you observed to a number you configured
Measure before optimising, too
The inverse mistake is cheaper but more common: optimising something that was never slow. It is worth actually timing the suspected bottleneck before doing the work, because a surprising proportion of the time the bottleneck is somewhere else entirely and the planned work would have achieved nothing.
Queries that execute in microseconds do not need an index. An index that already exists does not need adding. Both of those are real findings that delete planned work, and deleting planned work is the highest-value outcome available from a measurement.
The best result from a benchmark is discovering that the change you were about to make was unnecessary.
Speeding one thing up can multiply another
A last trap worth naming: work scheduled as a fraction of another process inherits that process's rate. A refresh that runs every fifth poll runs every twenty seconds at a four-second interval and every 3.75 seconds at 750ms — a five-fold increase in load that nobody asked for and nobody noticed, arriving as a side effect of an unrelated improvement.
Anything that should happen on a wall-clock cadence should be driven by a wall-clock timer, decoupled from whatever else happens to be ticking.