ExamFinch.com My Study

Study guide

6.1 Performance Analyzer and DAX Query View

Practice this exam

Microsoft Power BI Data Analyst PL-300

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the PL-300 Exam The Power BI Ecosystem

2 Chapter 1: Get or Connect to Data

1.1 Data Source Types and Connections 1.2 Storage Modes: Import, DirectQuery, and Direct Lake 1.3 Data Source Settings and Parameters

3 Chapter 2: Profile and Clean the Data

2.1 Data Profiling in Power Query 2.2 Resolving Errors, Nulls, and Data Quality Issues 2.3 Data Types and Type Detection

4 Chapter 3: Transform and Load the Data

3.1 Column Transformations and Data Types 3.2 Grouping, Aggregating, Pivoting, and Unpivoting 3.3 Merge Queries, Append Queries, and Relationship Keys 3.4 Query Folding and Load Performance

5 Chapter 4: Design and Implement a Data Model

4.1 Star Schema Design 4.2 Relationships, Cardinality, and Cross-Filter Direction 4.3 Table and Column Properties 4.4 Calculated Columns and Calculated Tables

6 Chapter 5: Create Model Calculations with DAX

5.1 DAX Fundamentals and Measures 5.2 The CALCULATE Function 5.3 Time Intelligence Measures 5.4 Statistical Functions, Semi-Additive Measures, and Calculation Groups 5.5 Essential DAX Patterns and Functions Reference

7 Chapter 6: Optimize Model Performance

6.1 Performance Analyzer and DAX Query View 6.2 Model Size Reduction and Cardinality Management 6.3 DAX Optimization Patterns

8 Chapter 7: Create Reports

7.1 Visual Types and Selection 7.2 Visual Formatting and Conditional Formatting 7.3 Copilot in Power BI Reports 7.4 Report Page Configuration and Slicers

9 Chapter 8: Enhance Reports for Usability and Storytelling

8.1 Bookmarks, Navigation, and Drillthrough 8.2 Sorting, Selection Pane, Mobile Layout, and Accessibility 8.3 Export Settings and Automatic Page Refresh

10 Chapter 9: Identify Patterns and Trends

9.1 The Analyze Feature and AI Visuals 9.2 Using Copilot to Summarize the Semantic Model 9.3 Advanced Analytics Patterns

11 Chapter 10: Create and Manage Workspaces and Assets

10.1 Workspaces, Apps, and Content Distribution 10.2 Subscriptions, Alerts, and Semantic Model Refresh 10.3 Dashboards and Advanced Distribution

12 Chapter 11: Secure and Govern Power BI Items

11.1 Row-Level Security (RLS) 11.2 Sensitivity Labels, Item Access, and Governance 11.3 Deployment Pipelines and Content Lifecycle

6.1 Performance Analyzer and DAX Query View

Key Takeaways Explain This Topic AI

Performance Analyzer times each visual, breaking the total into DAX query, DirectQuery, Other, and visual-display components.

Start recording, refresh/clear the visual cache, then interact so measurements reflect true cold-start performance.

DAX query view lets you write and test EVALUATE queries against the model without building visuals.

Long DAX time points to measure optimization; long DirectQuery time points to source optimization; long display time points to visual cardinality.

Copy a visual's query from Performance Analyzer and paste it into DAX query view to analyze and tune it.

Last updated: June 2026

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:

  • Metric Description
  • DAX Query Time for the engine to execute the DAX
  • Direct Query Time for the source to respond (DirectQuery only)
  • Other Power BI internal processing and waits
  • Visual Display Time to render the visual
  • Total Sum of components
  • Accurate Measurement

Start recording from the Performance Analyzer pane.

Clear the visual cache: click Refresh visuals in the pane (or Ctrl+Shift+F5 ).

Interact: change slicers, navigate pages.

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

  • Symptom Likely Cause Action
  • Long DAX query time Inefficient measures Optimize DAX (variables, fewer FILTERs)
  • Long DirectQuery time Slow source database Tune source, add indexes, use aggregations
  • Long visual display Too many data points Reduce cardinality, use Top N
  • Many visuals loading Overcrowded page Reduce visual count, use bookmarks/drillthrough

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.