Practice: Explain a Performance Difference

By the end of this lesson, you will be able to...

• Explain a performance difference with a named comparison, metric, and workload.

• Use degree modifiers such as slightly, much, too, and enough without overstating the evidence.

• Connect a result to a likely cause while keeping the cause separate from an unverified hypothesis.

• Write a short recommendation that states the benefit and the cost of an optimization.

Idea in one sentence: A useful performance sentence compares like with like, names the boundary, and explains what the difference changes for the system.

Core Insight

Consider a database endpoint that lists recent orders. The original query scans the whole orders table. A new composite index filters by customer_id and sorts by created_at.

The first status line says:

The indexed query is faster than the full scan.

This is a good start, but it leaves several questions open. Faster on which metric? With how many rows? Under a warm or cold cache? Is the improvement large enough to justify the index's storage and write cost?

A more useful line is:

The indexed query is 50 ms faster than the full scan on median latency for the 10,000-row customer workload.

The sentence names the property, direction, amount, and workload. It gives a reviewer something to verify instead of asking them to trust the adjective faster.

The Small Situation: Two Query Plans

The team runs both plans against the same staging dataset:

The indexed query is much faster on the median path, but its p95 is higher in this sample and it adds a write cost. A careful note can hold these facts together:

The indexed query is much faster than the full scan on median latency, but its p95 is slightly higher in this workload.

The word much is justified by the 90 ms versus 40 ms median. Slightly is more cautious about the p95 gap. If the sample is small, write appears slightly higher or give the numbers rather than presenting a stable law.

The trade-off is explicit:

The index reduces median read latency, but it increases storage and nightly write time.

An optimization is not a free improvement. The sentence should tell the next engineer what the system gains and what it spends.

Build the Explanation in Five Moves

Move 1: Name the two things

Keep the comparison target visible:

The indexed query is faster than the full scan.

Avoid an unexplained it or this option when the paragraph contains several plans:

It is faster.

If a reader cannot resolve it immediately, repeat the noun. Repetition is cheaper than a wrong performance comparison.

Move 2: Name the metric

Performance has many properties. Choose one:

faster on median latency
lower p95 latency
more efficient in rows examined
slower during writes

Do not compare a latency number with a category such as “reliability.” Write separate clauses when the properties differ:

The index lowers median read latency, while the full scan has a lower p95 in this sample.

Move 3: Name the workload and boundary

Add the request shape, dataset, cache state, or time window:

The indexed query is faster on the median path for recent orders from one customer.

If the claim applies only to a warm cache, say so:

The indexed query is faster than the full scan with a warm cache and the 10,000-row staging dataset.

This does not weaken the result. It identifies where the result was observed.

Move 4: Explain the mechanism without pretending certainty

The index examines fewer rows, which is a plausible mechanism for the lower median latency:

The indexed query is faster because it examines about 120 rows instead of scanning all 10,000 rows.

If the evidence does not prove causation, calibrate it:

The lower median latency is consistent with the index examining fewer rows, but the team still needs a cold-cache test.

Because is appropriate when the mechanism has been established. Consistent with is safer when the test only supports a hypothesis.

Move 5: State the trade-off and action

Close with a requirement-based recommendation:

Use the index for the read-heavy endpoint if the 12 GB storage cost and 18% write overhead fit the budget. Keep the full scan for the nightly batch until its p95 behavior is understood.

The recommendation is conditional. It does not say that an index is always better.

Do Not Mix Measurement Windows

Performance sentences become misleading when the two options were tested under different conditions. A full scan measured with a cold cache cannot be compared directly with an indexed query measured after several warm runs. The grammar may still look perfect:

The indexed query is faster than the full scan.

Before repeating the sentence, align the test:

Both plans were measured with a warm cache, the same customer workload, and the same five-minute window. The indexed query is faster on median latency under those conditions.

If the windows cannot be aligned, state that limitation:

The indexed query appears faster, but the scan was measured with a cold cache, so the comparison is provisional.

This is especially important for as...as and not as...as. Equality is a strong statement about matching values, so the evidence must match too:

The two plans are not as easy to compare as the dashboard suggests because their cache states differ.

The sentence may feel less decisive, but it prevents a later reader from treating an unfair benchmark as a stable property of the system. A precise limitation is part of the performance explanation, not an apology for incomplete work.

Put the Number Beside the Adjective

Words and numbers do different jobs. The number gives the measurement; the adjective gives the relationship a reader can reuse in a sentence. Keep them together when a status update needs both:

The indexed query is 50 ms faster on median latency: 40 ms versus 90 ms.

The next sentence can carry the non-performance cost:

The index adds 12 GB of storage and 18% to nightly write time.

This pair is easier to audit than The index is much better. It also helps a non-native reader learn the natural collocation faster on median latency while seeing exactly what the adjective refers to. If the numbers change in a later run, the sentence can be updated without changing the reasoning pattern.

That separation protects the decision record: a later engineer can challenge the measurement, the interpretation, or the threshold independently instead of arguing about one overloaded word. Numbers support the adjective; they do not replace the explanation. Keep checking.

Calibrate the Degree Words

Degree modifiers change how strong the sentence sounds. Use them as compact summaries of evidence, not as decoration.

The indexed query is slightly faster than the full scan.
The indexed query is much faster than the full scan.
The full scan is too slow for the 200 ms read budget.
The indexed query is fast enough for the interactive endpoint.

The first two sentences need a comparison boundary. “Much faster” might describe 90 ms versus 40 ms, but it should not be copied to a different workload without checking the numbers. The last two connect degree to a requirement. Too slow means the query crosses a limit; fast enough means it meets one.

Do not stack modifiers or forms:

The indexed query is more faster and much best.  # incorrect
The indexed query is considerably faster on median latency. # possible when evidence supports it

The strength should come from the metric, not from several adjectives competing for attention.

A Worked Trace from Raw Data to a Status Line

Start with the raw observation:

full scan: median 90 ms, p95 160 ms, 10,000 rows examined
indexed query: median 40 ms, p95 180 ms, 120 rows examined

Trace 1: Pairwise comparison

The indexed query is faster than the full scan on median latency.

Trace 2: Add the amount and workload

The indexed query is 50 ms faster than the full scan on median latency for the 10,000-row customer workload.

Trace 3: Add the counter-signal

The indexed query is 50 ms faster on median latency, but its p95 is 20 ms higher in this sample.

Trace 4: State the likely mechanism

The index examines about 120 rows instead of 10,000, which likely explains the lower median latency.

Trace 5: State the decision boundary

Use the index for interactive reads if the higher p95 and 18% write overhead fit the service budget; do not use this canary alone to claim that it is safer for every workload.

Each move adds information that changes the decision. The final sentence is longer than The indexed query is faster, but it protects the reader from a familiar mistake: turning one happy-path metric into a universal architecture claim.

Practice with As...As, Too, and Enough

The comparison cluster is easier to remember when the patterns describe the same evidence from different angles:

The indexed query is as fast as the cache-hit path on the median request.
The full scan is not as fast as the indexed query for customer lookups.
The full scan is too slow for the interactive read budget.
The indexed query is fast enough for the endpoint, but not necessarily for the write-heavy batch.

Only use the first sentence if the two paths really have equal measured latency. Only use too slow or fast enough if a budget exists. Grammar makes the relationship visible; measurement decides whether the relationship is true.

Common Confusions

Confusion: “faster” explains why

Better model: it states a relationship, not a mechanism. Add rows examined, plan shape, or another observed signal, and mark a hypothesis as a hypothesis.

Confusion: median performance is the whole user experience

Better model: check p95 or p99, error rate, memory, and write impact when those properties affect the requirement. A lower median can coexist with a worse tail.

Confusion: an index is always better than a scan

Better model: an index trades storage and write work for read behavior. It can be too expensive for a small table or a write-heavy path.

Confusion: a causal connector proves the mechanism

Better model: use because when the mechanism is established; use likely, appears, or is consistent with when the test only supports an explanation.

Confusion: a long sentence is automatically precise

Better model: add only details that change the claim: metric, workload, mechanism, counter-signal, or decision condition. A paragraph of unrelated numbers is not a comparison.

Check Your Understanding

Check: Which sentence compares like with like and names a boundary?

A. The indexed query is better.

B. The indexed query is 50 ms faster than the full scan on median latency for the customer workload.

C. The indexed query is more reliable than 10,000 rows.

Think first, then reveal.

Answer: B. It compares two query plans on one metric and states the workload.

Check: Which explanation is appropriately calibrated when causation is not proven?

A. The index definitely fixes every latency problem.

B. The lower median latency is consistent with the index examining fewer rows, but a cold-cache test is still needed.

C. The query is fast because indexes are always best.

Think first, then reveal.

Answer: B. It offers a plausible mechanism and keeps the missing test visible.

Check: Which recommendation includes a trade-off?

A. Use the index because it is the fastest.

B. Use the index for read-heavy traffic if the storage and write overhead fit the budget.

Think first, then reveal.

Answer: B. It connects the benefit to a workload and names the cost that could change the decision.

Practice: Explain a Cache Difference

You receive this data from a canary:

• local cache: 25 ms median read, 80 ms p95, simple deployment, stale values after a node restart;
• shared cache: 25 ms median read, 95 ms p95, more setup, consistent values across nodes.

Write four sentences:

1. an equality sentence about median latency;
2. a sentence using not as...as or a comparative for p95;
3. a sentence explaining the operational trade-off;
4. a conditional recommendation for a service that requires cross-node consistency.

One possible answer is:

The shared cache is as fast as the local cache on median reads in the canary. The shared cache is not as fast as the local cache on p95 latency. It requires more operational setup, but it avoids stale values across nodes after a restart. Use the shared cache when cross-node consistency is required despite the higher tail latency and setup cost.

Check your draft:

• Did you compare the same metric on both sides?
• Did you name the canary or workload?
• Did you keep median and p95 separate?
• Did you state what the chosen design costs?
• Is the recommendation tied to a requirement rather than a universal adjective?

Daily Practice Lines

• The indexed query is faster than the full scan on median latency.
• The full scan is too slow for the interactive read budget.
• The shared cache is as fast as the local cache on median reads, but it costs more to operate.

Say the metric after each line: median latency, interactive budget, and operational effort. This small pause prevents faster, too slow, and as fast as from becoming empty habits.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Comparative and superlative adjectives - Focus: form comparisons and use degree modifiers accurately.
• [ARTICLE] Microsoft Writing Style Guide: Grammar - Focus: explain technical results with direct, scoped wording.

Key Takeaways

• Explain performance with a comparison, metric, workload, and evidence boundary.
• Use slightly or much only when the measured gap supports the degree.
• Separate an observed difference from a proposed mechanism or hypothesis.
• A performance optimization carries a trade-off in storage, writes, memory, tail latency, or operations.
• End with a conditional recommendation tied to the service requirement.