Tableau / Advanced: quality and governed delivery / Lesson 14

Performance evidence and model reduction

Investigate slow interactions by separating source queries, calculation, marks and layout while preserving analytical meaning.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Define a reproducible slow interaction and baseline.
Assess mark count and data reduction without losing required detail.
Distinguish diagnostic recordings from invented benchmarks.

Start with one interaction

A performance investigation names the workbook, sheet, selection, expected result and slow observation. Source connection, query compilation/execution, extract work and layout can contribute differently. A large source does not automatically explain every slow action, and a small view can still use an expensive expression. Performance Recording can provide event evidence in supported Desktop scenarios, but interpretation requires the interaction context. This course records nothing, runs no benchmark and invents no engine timing. The first record is an unexecuted investigation plan, separating a testable hypothesis from a broad claim that the whole server is slow.

text Unexecuted performance hypothesis

interaction:select Tea in the overview
expected data:Sales42 with documented target sheets
hypothesis:unnecessary mark/detail work delays layout
needed evidence:comparable event recording + unchanged expected results

The record contains no captured timings and requests no server or source operation.

Reduce only unneeded detail

Removing unused fields, limiting excessive marks or aggregating data can reduce work, but each can change capabilities. Summarizing sales to month-product removes order-level drill and distinct-order semantics unless preserved elsewhere. Hiding a field is not necessarily the same as removing it from every query or extract. Inventory calculations, filters, actions, security and downstream consumers before reduction. The second program compares synthetic line rows with grouped product amounts and shows fewer groups with the same sales total. It does not measure Tableau memory, compression or execution time, and it cannot prove that lost detail was unnecessary.

python Synthetic grouping-size comparison

rows = [("Tea", 12), ("Coffee", 18), ("Tea", 30)]
groups = {}
for product, amount in rows:
    groups[product] = groups.get(product, 0) + amount
print(len(rows), len(groups))
print(sum(groups.values()))

Expected output

3 2
60

Three rows become two product groups with total 60. This is not a performance or compression measurement.

Separate live and extract costs

A live query can be dominated by source and network behavior, while an extract can shift work into local or hosted processing. Switching connection type is not a universal fix for an incorrect model or unbounded detail. Relationships, joins, filters and calculations influence generated work, so inspect the exact view rather than tuning from a generic rule. Avoid claiming every LOD or table calculation is slow. A complex calculation may be necessary and perform adequately; a simple expression can be costly over an unintended population. Preserve correctness first, then gather evidence identifying the demonstrated bottleneck.

Compare like states and one change

Choose one hypothesis, one justified change and equivalent selections before and after. Cache state, concurrent workload, source conditions and device can affect observations, so record them with limits. A single faster run cannot establish a universal percentage improvement. Review the actual event categories and keep sensitive query text or source identifiers within approved handling. Do not run load generation, database administration or broad diagnostics to make the course appear practical. A safe small synthetic review can still distinguish semantic correctness from a future authorized performance measurement without touching any configured service.

Publish a bounded record

A useful optimization record includes initial interaction, source mode, model/view detail, expected values, diagnostic evidence, exact change and capability tradeoffs. Recheck affected totals, actions and security after reduction. This course executes only the three-row grouping example and no performance recorder or source query. Actual timings remain unexecuted. A smaller workbook or fewer marks can be a promising hypothesis, not proof of user benefit. Keep the conclusion proportional to observed evidence and identify remaining environment checks rather than replacing them with a universal capacity, hardware or tuning prescription.

Common errors and fixes

Fewer rows are called an equivalent improvement automatically

Why it happens: Lost drill, distinct counts or security dependencies were ignored.
How to fix it: Review capability changes and preserve required analytical grain.
Prevent it next time: Keep a dependency inventory before reduction.

A slow page is blamed on every LOD expression

Why it happens: No event or query evidence isolated the cause.
How to fix it: Measure the specific interaction through an authorized diagnostic plan.
Prevent it next time: Separate hypotheses from measured bottlenecks.

One fast run becomes a universal speed promise

Why it happens: Cache and workload conditions were not controlled or reported.
How to fix it: Compare equivalent states and scope the conclusion to actual observations.
Prevent it next time: Record uncertainty and avoid unmeasured percentages.

Check your understanding

1. Why does grouping three lines into two products not prove a safe performance improvement?

Show worked solution

The count shrinks and total stays 60, but order detail, distinct-count meaning or action targets may be lost. No engine timing was measured. Verify required capabilities and actual comparable performance before approval. A mathematically preserved total covers only one invariant of the workbook contract.

2. What should a performance handoff state when only the Python example ran?