5 exercises — practice expressing performance improvements accurately: "X is 3x faster", "40% improvement", and how to compare baseline vs. improved numbers without ambiguity.
0 / 5 completed
Key phrases for comparing performance numbers
"Reduced from [baseline] to [new value] — a [X]% reduction / [N]x improvement." (most precise)
"3x as fast" (preferred over "3x faster" which is ambiguous).
"40% improvement in latency" = new latency is 60% of the baseline (latency × 0.60).
"Under a sustained load of [N] concurrent users on [hardware/environment]."
"Up to X" — always specify conditions; "up to" alone is cherry-picking.
1 / 5
A colleague says "The new query is 3x faster than the old one." The old query took 900ms. What does "3x faster" mean, and what is the new query time?
Option B correctly identifies the famous ambiguity in "Nx faster" language. In colloquial usage, "3x faster" almost always means "3x as fast" (the new thing is 3 times faster than the original), giving 300ms. However, mathematically, "faster by 3x" could mean the improvement equals 3 times the baseline: 900ms × 3 = 2,700ms improvement, meaning the new time is 900ms - 2,700ms, which is negative — nonsensical. In professional communication: (1) prefer "3x as fast" over "3x faster" when you mean the new value is 1/3 of the old one, (2) or use "reduced from 900ms to 300ms" — unambiguous. (3) "40% faster" is clearer than "1.67x faster" for small improvements. Rule: for performance claims, give the absolute numbers alongside the multiplier.
2 / 5
A performance report says "We achieved a 40% improvement in query latency." The baseline was 250ms. What is the new latency?
Option B is correct: 250ms × (1 - 0.40) = 250ms × 0.60 = 150ms. A "40% improvement in latency" means latency is reduced by 40%, so the new value is 60% of the original. Key formula: new value = baseline × (1 - improvement%). Common errors: (1) Option A adds 40ms to the baseline — this confuses absolute and percentage change, (2) Option C applies 40% directly to get the new value — this gives the reduction amount, not the new value, (3) Option D adds 40% to the baseline — this is an increase, not an improvement. In performance reporting: "40% improvement" = the metric is 40% smaller. Always confirm: "improvement" means the number goes down for latency, goes up for throughput. State the absolute numbers alongside percentages to remove ambiguity.
3 / 5
Two systems are compared: System A processes 1,200 req/s, System B processes 2,100 req/s. How do you correctly express the performance difference?
Option B is the most complete and accurate comparison. It provides: (1) the percentage difference — (2,100 - 1,200) / 1,200 = 75% more, (2) the absolute numbers in parentheses — this lets anyone verify the claim, (3) the multiplier — 2,100 / 1,200 = 1.75x. Providing multiple representations (%, multiplier, absolute) gives the fullest picture. Option A gives only the absolute difference (900 req/s) — correct but incomplete and lacks context (is 900 req/s large or small relative to baseline?). Option C says "75% faster overall" — "overall" is vague; this should be specific to throughput. Option D gives the inverse comparison (A vs. B) — this is mathematically valid: (2,100 - 1,200) / 2,100 = 43% — but is potentially confusing when the question is about B's advantage. Best practice: when comparing, state baseline / comparison / percentage / multiplier.
4 / 5
A benchmark shows the new algorithm is "10x faster" on a test dataset of 1,000 items. A colleague says "We should announce this in the release notes." What should you verify first?
Option B identifies the critical benchmark validity concern: dataset size effect. Many algorithmic improvements show dramatic gains on small inputs but much smaller gains on large inputs, due to: (1) O(n log n) vs. O(n²) algorithms — the difference is large at small n and enormous at large n, but the 10x benchmark was taken at n=1,000, not n=1,000,000, (2) cache effects — small datasets may fit entirely in CPU cache, making memory access patterns irrelevant (they matter enormously in production), (3) JVM warmup, GC pressure, and other factors that only appear at sustained production load. Before publishing a performance claim: test at production-scale data, under production-like load, for production-like duration. Option A blindly trusts benchmark conditions. Option C is secondary. Option D is irrelevant for relative comparisons (both old and new should run on the same hardware).
5 / 5
Which sentence most precisely communicates a performance improvement in a technical report?
Option B is the benchmark of technical performance reporting. It contains every required element: (1) baseline value (340ms), (2) new value (85ms), (3) percentage change (75% reduction), (4) multiplier (4x), (5) test conditions (500 concurrent users, production hardware), (6) metric specification (median latency — not mean, not max). Option A uses "significantly" — a vague qualifier with no numerical grounding. Option C says "up to 4x in some cases" — "up to" is the language of marketing, not engineering; it cherry-picks the best result. Option D uses "substantially" — another unmeasured qualifier. Rule for performance writing: every claim should answer five questions — what metric, what baseline, what improvement, under what conditions, at what statistical percentile.