3.3.2. Performance Analyzer and DAX Query View
💡 First Principle: You can't optimize what you haven't measured. Performance Analyzer records how long each visual takes and why; DAX query view lets you run, inspect, and refine the exact query a visual sends. Used together, they move tuning from guesswork to evidence.
Performance Analyzer (Optimize ribbon > Performance Analyzer in Desktop): select Start recording, then Refresh visuals or interact with the page. Each visual reports its total duration broken into:
| Component | What it measures | High value suggests |
|---|---|---|
| DAX query | Time for the engine to return results | Inefficient measure, large or poorly designed model, expensive relationships |
| Visual display | Time to render (including images and custom visuals) | Too many data points, complex custom visual, heavy formatting |
| Other | Queueing, waiting for other visuals, background processing | Too many visuals on the page |
From any visual you can Copy query, then paste it into DAX query view (or an external tool such as DAX Studio) to examine it. Export the session to JSON to share results.
DAX query view (in Desktop) lets you write and run DAX queries that begin with EVALUATE, see results as a table, and use quick queries from the Data pane: show top 100 rows of a table, show column statistics, define and evaluate a measure, or define all measures in the model. You can edit a measure's definition in a DEFINE MEASURE block, test it, and then update the model with the change. Copilot can also help write and explain DAX queries here where available. It's the right tool when a stem says "test a measure's output without building a visual" or "investigate the query generated by a slow visual."
DEFINE
MEASURE Sales[Sales PY] =
CALCULATE ( [Total Sales], SAMEPERIODLASTYEAR ( 'Date'[Date] ) )
EVALUATE
SUMMARIZECOLUMNS ( 'Date'[Year], "Sales", [Total Sales], "PY", [Sales PY] )
What to fix once you've found the bottleneck: slow DAX → simplify measures, use variables (VAR) to avoid recomputing, filter columns rather than whole tables in CALCULATE, avoid iterating huge tables unnecessarily; slow relationships → remove unneeded bidirectional filters and many-to-many relationships, ensure keys are integers and unique; slow visuals → reduce data points, limit visuals per page, use the Apply button on slicers in DirectQuery models; slow everything → revisit model size (3.3.1).
⚠️ Exam Trap: When Performance Analyzer shows a visual with a short DAX query but a long visual display time, rewriting the measure won't help. The fix is on the visual: fewer data points, a simpler visual type, or removing a heavy custom visual.
Reflection Question: A page with 25 visuals shows most visuals with small DAX and display times but large "Other" times. What does that pattern mean, and what design change addresses it?
