cswork / libraryOpen practice workspace

Articles

Power BI Performance Interview: Read a Slow Visual Before Rewriting DAX

Prepare for a Power BI performance interview with slow-visual cases. Read query, display, and waiting evidence before rewriting DAX or changing storage.

A report feels slow. The interviewer points at a matrix and asks you to optimize its DAX. Before touching the measure, ask what happened between the user's click and the finished visual. A slow interaction can involve a model query, an external source, drawing the result, or waiting behind other work. Changing the formula addresses only some of those possibilities.

A strong Power BI performance interview answer starts with a reproducible interaction, reads the evidence for that visual, and proposes a change whose effect you can test. It also protects the report's meaning: a quicker number is useless if it drops customers, changes the total, or exposes rows to the wrong user.

Evidence boundary: tool behavior below comes from linked Microsoft and DAX Studio documentation. The timing tables, datasets, and interview prompts are original teaching examples, not captured production traces or reported employer questions. We have not executed these examples in Power BI. No candidate report establishes a universal interview format or expected speedup.

Reproduce one interaction before choosing a fix

Suppose the complaint is “the regional revenue page is slow.” That description is too broad to evaluate a rewrite. Opening the page, changing a slicer, expanding a hierarchy, and hovering over a tooltip are different experiments.

For an original interview case, define the interaction as: open the regional revenue page, select April in the month slicer, and wait until the revenue matrix finishes updating. Record the region selection, matrix hierarchy level, user or test role, model version, storage mode, and where the report runs. Ask whether the problem affects every user or only particular roles and data selections.

Then define the success condition. The matrix must show the same revenue definition, rows, subtotals, and allowed data. The product owner wants the April selection to become usable faster; they have not authorized removing detail or changing freshness. Those constraints keep an attractive shortcut from quietly becoming a different report.

Official tool behavior: Microsoft documents Performance Analyzer in Power BI Desktop and the service's editing experience. In Desktop, open it from Optimize. Start recording, reproduce the action, stop recording, and export the results if needed. You can analyze an individual visual and copy its query. Microsoft Performance Analyzer.

Keep the initial trace before editing. Write down which run was the first after opening the report and which was a repeat. Do not label every repeat “cold” or assume clearing the displayed recording clears model caches. If you cannot control cache state, disclose that limitation and compare comparable runs.

Read the categories without inventing a page total

Official definitions: Performance Analyzer separates DAX query, visual display, and Other; DirectQuery appears when applicable. Other includes preparation, waiting for other visuals, and background processing. Microsoft warns that reported durations can include queued time on shared work. Copy query can include translated SQL or KQL for DirectQuery. Microsoft Performance Analyzer.

Here is an original diagnostic exercise. The milliseconds are deliberately invented to help you choose the next experiment.

VisualDAX queryVisual displayOtherFirst hypothesis to test
Revenue card A4590080Drawing or visual configuration dominates
Regional matrix B2,10012080The model query deserves inspection
Trend chart C60402,400Preparation or competing work needs isolation

The correct answer is not “rewrite all three measures.” For A, inspect what the visual draws. For B, investigate the query and model. For C, isolate the interaction before assigning the delay to its measure.

These rows do not establish root causes. A display-heavy visual could have several rendering costs; a query-heavy visual could involve relationships, grouping, or source work. Explain the uncertainty, then choose a test that separates plausible causes.

Do not add every visual's elapsed duration and call the result page load time: work can overlap or wait. Likewise, if a DirectQuery visual shows a 2,800 ms DAX query and 2,500 ms DirectQuery component, do not automatically report 5,300 ms of independent query cost. Establish the measurement boundaries first. Measure the actual user interaction separately when page responsiveness is the outcome.

Case 1: the query is quick but the visual is slow

For card A, the original trace suggests a rendering investigation. Ask about the visual type, images, formatting, and output density. A custom visual and a native card might present similar information with different rendering behavior; that is a hypothesis to test, not a promise that the native version wins.

Official design guidance: Microsoft recommends evaluating the number of visuals, limiting unnecessary detail, and testing custom visuals as part of report optimization. Its guidance separates data source, semantic model, visualization, and environment concerns. Microsoft optimization guidance.

In a working copy, change one display feature while retaining the same measure and filters. If the query remains comparable but display time falls repeatedly, that supports a rendering explanation. If it does not, keep investigating rather than claiming a win from a cleaner-looking page.

Avoid silently replacing a complete customer list with a Top 10 list. That may reduce work, but it changes the question the report answers. A summary with drillthrough can be a good product decision when the owner approves it; present that decision separately from a behavior-preserving optimization.

The interviewer may ask, “Why didn't you simplify the measure first?” Answer with the evidence: the query component was small relative to drawing, so your first experiment targeted the larger observed component. You remain willing to revisit the measure if later traces justify it.

Case 2: the model query is expensive

For matrix B, copy the query and preserve its filters and grouping. A visual query can contain scaffolding for sorting and row limits. Removing unfamiliar clauses immediately risks benchmarking a query that no longer represents the visual.

Inspect the matrix's grain: how many groups must it evaluate, and what changes when a user expands the hierarchy? Ask whether one measure is costly or whether the selected dimensions and relationships create an expensive result. Test removing a measure or a grouping field in the working copy, then restore the original before comparing another hypothesis.

Official deeper tracing: DAX Studio distinguishes client elapsed timing from server timing. Its Server Timings trace exposes server processing and storage-engine requests, with formula-engine time derived from the trace metrics. Its documentation says tracing requires server admin rights. Use the access already available; a restricted interview environment may permit only explanation and exported evidence. DAX Studio Server Timings.

A large formula-engine component can motivate investigation of repeated evaluation or iteration. It does not prove that every iterator is wrong. Consider this original revenue fixture:

ItemQuantityUnit priceRequired line revenue
A21020
B13030
Total50
Revenue =
SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

Replacing this expression with SUM(Sales[UnitPrice]) produces 40 for the fixture, not 50. The expression is shorter, but its meaning is different. This arithmetic counterexample is not a Power BI execution result; verify actual model behavior in the permitted environment.

A precomputed line-revenue column could be considered if its definition, storage cost, and refresh behavior fit the model. Explain why it preserves the business calculation before discussing speed. Test both filtered results and totals; do not assume that matching one visible cell establishes equivalence everywhere.

Case 3: Other dominates, or DirectQuery is involved

For chart C, create an isolated diagnostic page or analyze the visual individually while retaining equivalent context. A chart with no slicers or role restrictions is not a valid substitute for the original filtered chart.

If the chart becomes responsive in isolation, reintroduce neighboring visuals and interactions progressively. This tests whether competition on the original page explains the delay. If the delay remains, your waiting hypothesis is weakened. Other is a useful signal for investigation, not a precise label for one hidden subsystem.

For a DirectQuery variant, follow the request beyond DAX. Official architecture: Microsoft explains that DirectQuery queries underlying sources at report time, with source performance and network or gateway overhead affecting responsiveness. It also describes load from visual queries and user interactions. Microsoft DirectQuery guidance.

Ask whether the translated query sends the intended filters, how many rows return, and whether the source's execution plan supports the joins and predicates. Coordinate with the source owner rather than declaring the database slow from a single report timing. A fast source execution with a slow report request warrants a different investigation from a source query that itself takes seconds.

Official folding boundary: Microsoft's query-folding guidance distinguishes DirectQuery or Dual requirements from Import refresh optimization. Folding pushes supported transformations to the source. Microsoft query-folding guidance.

Changing storage mode is therefore an architectural proposal, not an automatic interview fix. Explain the freshness, security, capacity, and maintenance consequences. A cached result that violates the required freshness window does not satisfy the original task.

Verify improvement without losing correctness

Use a small comparison record for each proposed change: original interaction, hypothesis, single change, repeated timings, result checks, and the condition under which you would revert it. Keep first-run observations separate from repeat-run observations. Alternate versions when practical so a steadily warming environment does not masquerade as a successful rewrite.

For the revenue matrix, compare detailed rows, regional subtotals, grand total, empty selections, and an authorized restricted-role fixture. Check that blank and zero remain distinguishable when the business definition requires it. Include the largest relevant selection, not only the easy month used while editing.

If results differ, explain whether the original was incorrect, the new version is incorrect, or requirements were ambiguous. Resolve that question before presenting a performance gain. “Both versions agree” is also insufficient when both share the same bug; reconcile a small fixture against an independently calculated expected result.

Keep refresh diagnostics separate from visual diagnostics. Official tool scope: Microsoft describes Power Query Query Diagnostics for query evaluation and Performance Analyzer for report visuals; capacity monitoring is another layer. Microsoft performance monitoring guidance.

An Import model taking too long to refresh does not, by itself, establish that the matrix's DAX is expensive. Name the slow operation precisely so the interviewer sees why you chose the tool.

Practice the diagnostic conversation

Try a concise answer to the original case:

I would reproduce the April slicer change with the same region, hierarchy, and role, then preserve a Performance Analyzer recording. If query time dominates, I would inspect the copied query and model; if display dominates, I would test rendering; if Other dominates, I would isolate competing work. I would change one cause at a time and repeat comparable runs. Before accepting the change, I would reconcile revenue rows and totals and verify the restricted-role result. I would report remaining uncertainty rather than promise a speedup before testing.

Practice questionApply it to this interview
Describe building and improving a dashboardExplain the user complaint and evidence behind an improvement.
Design a Monitoring Dashboard with Explicit Latency GoalsSeparate freshness requirements from interaction latency.
Design a Payment-Count Dashboard That Scales with Readers and UpdatesDiscuss workload and concurrency before changing storage.
Answer SQL And Data Warehouse Fundamentals For A Data Engineering InterviewTrace source queries, grouping, and data grain.
Web Application Performance DebuggingForm a hypothesis, isolate a cause, and verify a result.

Choose one case and explain the observation that would make you abandon your first hypothesis.

Sources and Further Reading