6.1 Performance Analyzer and DAX Query View

Quick Answer: Performance Analyzer (View tab) records how long each visual takes to load, split into DAX query time, DirectQuery time, and visual rendering time. Clear the cache first for accurate results. DAX query view lets you write and test DAX queries directly, isolating slow measures before they reach reports.

Performance Analyzer

Open it with View > Performance Analyzer > Start Recording. For each visual it records:

Accurate Measurement

1. Start recording from the Performance Analyzer pane.
2. Clear the visual cache: click Refresh visuals in the pane (or Ctrl+Shift+F5).
3. Interact: change slicers, navigate pages.
4. Stop recording and review.

Without clearing the cache, Power BI may serve cached results, so visuals look faster than a first-time user would experience.

Interpreting Results

Click Copy query beside any visual to capture the exact DAX sent to the engine, then paste it into DAX query view to study and optimize it.

DAX Query View

DAX query view is a dedicated view (left sidebar, or View > DAX query view) for writing and testing queries with EVALUATE.

EVALUATE Products

EVALUATE FILTER(Products, Products[Category] = "Electronics")

EVALUATE
SUMMARIZECOLUMNS(
    Products[Category],
    "Total Revenue", SUM(Sales[Amount]),
    "Order Count", COUNTROWS(Sales))

DEFINE
    MEASURE Sales[Test Revenue YTD] = TOTALYTD(SUM(Sales[Amount]), 'Date'[Date])
EVALUATE
SUMMARIZECOLUMNS('Date'[Month Name], "YTD Revenue", [Test Revenue YTD])

DAX query view lets you test measures before adding them, debug by examining intermediate results, compare alternative DAX, explore data without visuals, and validate against expected values. It also offers Copilot-assisted query authoring and a one-click "quick query" to preview any table.

Model Performance Strategies

Reduce model size. Remove unused columns and rows, lower cardinality, and avoid calculated columns when Power Query can do the same work.

Optimize data types. Prefer Whole Number over Decimal where possible, use Date instead of Date/Time when no time is needed, and avoid high-cardinality text for filtering.

Reduce granularity. If reports only need daily figures but data is per-second, aggregate in Power Query (Group By) before loading; smaller tables mean faster queries.

Improve relationships. Use integer keys (faster than text), keep a clean star schema, minimize bi-directional filtering, and set Assume Referential Integrity for DirectQuery.

Optimize measures. Use variables to avoid recomputation, prefer SUM over SUMX when no row-level math is needed, use DIVIDE() instead of IF division checks, minimize FILTER() inside CALCULATE, and avoid DISTINCTCOUNT on very high-cardinality columns.

On the Exam

The PL-300 tests using Performance Analyzer to find slow visuals, interpreting its breakdown (DAX time vs. display time), writing EVALUATE queries in DAX query view, and strategies for reducing model size and improving performance, including the impact of cardinality on compression and query speed.

A Repeatable Tuning Workflow

Performance Analyzer is most valuable as the front of a disciplined loop. First, measure: clear the cache, record, and interact so you capture realistic cold-start timings for every visual on the page. Second, locate: sort by Total and read the breakdown, the split between DAX query time, DirectQuery time, and visual display time tells you where the cost lives before you change anything. Third, isolate: copy the slow visual's query and run it in DAX query view so you can iterate on the measure without the noise of rendering. Fourth, fix and re-measure: apply one change, clear the cache, and confirm the improvement.

Changing several things at once is the most common way teams convince themselves something helped when it did not.

Reading the Breakdown Correctly

The component split is the whole point. A large DAX query time means the formula or model is the bottleneck, optimize the measure or reduce cardinality. A large DirectQuery time means the source database is slow, tune the query at the source, add indexes, or introduce aggregations. A large visual display time with small query time means the visual is rendering too many points, reduce the data shown with Top N, a filter, or a less granular axis. "Other" time often reflects waiting on the query queue when many visuals fire at once, which points to having too many visuals on one page.

DAX Query View as a Testing Harness

DAX query view turns the model into something you can unit-test. Using DEFINE MEASURE, you can prototype a measure, run it against SUMMARIZECOLUMNS to see its values across categories, and compare two candidate formulas side by side before committing either to the model. It also surfaces Copilot-assisted query generation and one-click table previews. For exam purposes, remember that DAX queries begin with EVALUATE and return a table, and that this view, not the report canvas, is the right place to validate and benchmark DAX.