Numbers, units, and bits
From 120 ms to 90 ms: what is the percentage decrease?
Tools to use
An improvement report might say '25% faster', '33% faster', or '75% of the original'. The same measurements can produce different figures because the denominators and measured quantities differ. Before hunting for an arithmetic error, identify the baseline and the change being described.
Use the percentage tool to compare illustrative processing times of 120 ms and 90 ms. It calculates from supplied values rather than measuring a service. It can calculate even when the measurements were made under incompatible conditions, so a result does not establish a fair comparison.
Divide the 30 ms reduction by the original 120 ms
In change mode, enter 120 as the original and 90 as the new value. The result is -25%, calculated as (90 - 120) / 120 × 100. The negative sign means the duration decreased. 'Processing time decreased by 25%' is clearer than treating a negative percentage as worse performance.
before = 120 ms
after = 90 ms
difference = -30 ms
change = -25%Align units before entering the values. The tool cannot infer that 120 ms and 0.09 seconds use different scales if entered as 120 and 0.09. Although the resulting ratio is dimensionless, both source values must use the same scale. Convert milliseconds and seconds or bytes and kilobytes before calculating the percentage.
75% remaining is not a 75% reduction
In percentage mode, enter 90 as the part and 120 as the base: the result is 75%. This describes how much of the original duration remains. Since 75% remains, 25% was removed. A report headed 'reduction' should not paste the 75% proportion as if it were the decrease.
A genuine 75% reduction from 120 ms would leave 30 ms, not 90 ms. Especially in short labels, distinguish '75% of the original', '25% less', and '75% less'. Correct arithmetic does not prevent misleading conclusions when the accompanying wording names the wrong quantity.
The reverse change is not the same percentage
Swap the values to original 90 and new 120: the increase is approximately 33.3333%. The absolute difference is still 30 ms, but the denominator is now 90. Percentage changes are not symmetric. Reversing the comparison changes more than the sign.
Similarly, increasing 100 by 20% gives 120; reducing that by 20% gives 96, not 100, because the second baseline is larger. Before combining discounts or capacity changes by adding percentages, check whether their baselines differ. Calculate sequential changes in their actual order.
How does a shorter duration affect throughput?
Assume strictly sequential work with no other waiting. At 120 ms per item, throughput is about 8.333 items per second; at 90 ms, about 11.111. Throughput increases by approximately 33.333%, consistent with a 25% duration reduction because the comparison uses reciprocal quantities.
Real services have concurrency, queues, external calls, and non-CPU limits. The reciprocal model cannot guarantee 33% more server capacity. Separate the measured claim—duration per item decreased 25%—from the conditional model of roughly 33% more sequential completions under unchanged conditions.
An error rate falls from 2% to 1%
Use percentage points for the direct difference between rates: 2% to 1% is a fall of one percentage point. Relative to the original 2%, it is a 50% reduction. Change mode with 2 and 1 yields -50%. 'Down 1%' leaves the interpretation ambiguous.
Counts matter too. Two versus one failures in 100 requests and 2,000 versus 1,000 in 100,000 show the same rate change but provide different amounts of evidence. This tool does not assess statistical significance or causation. A percentage calculation alone cannot establish whether a change is random variation or an intervention's effect.
How should you describe an increase from zero?
A zero baseline would require division by zero, so the tool rejects an ordinary percentage-change result. Calling zero to one a 100% increase is inappropriate. Report the counts or state change instead: 'increased from zero to one' or 'one new occurrence'.
A tiny nonzero baseline can still produce a large percentage: one to ten is a 900% increase but only nine additional occurrences. A large percentage alone hides scale. With small or negative baselines, consider whether the conventional formula expresses the intended meaning and also report absolute changes.
Keep the original measurements in the report
Report 'mean duration fell from 120 ms to 90 ms: 30 ms lower, a 25% reduction from the original'. Align means with means, medians with medians, and measurement conditions. Comparing the fastest new request with an old average or worst case does not establish an improvement even if the arithmetic is correct.
The tool verifies the arithmetic on supplied values. Baseline choice, the definition of improvement, and the strength of evidence are separate decisions. Inspect the reverse change, remaining proportion, and absolute difference before writing the conclusion so the percentage does not lose its context.
Can two error percentages simply be averaged?
Suppose morning traffic has 10 errors in 100 requests, or 10%, and afternoon traffic has 9 in 900, or 1%. Averaging the percentages gives 5.5%, but the day's rate is 19/1000=1.9%. Equal weighting of periods ignores their different request counts. Add the original counts first and enter part 19, base 1000. Percentages alone omit the denominators needed to reconstruct the combined rate.
For a before-and-after comparison, align the population as well. An error rate across all requests and one for a single feature do not measure the same target. Check time windows, included features and the definition of failure before calculating a change. Numeric inputs being accepted does not make the comparison meaningful. Document aggregation changes alongside the values so readers can distinguish improvement from a changed definition.