Microsoft Power BI Quiz: Performance Analyzer

10 questions · exam conditions

0:00

Performance AnalyzerQuestion 1 of 10

You record a report page by using Performance Analyzer and then select Refresh visuals. The recorded totals are: Sales card, $420\text{ ms}$ ; Revenue by region chart, $1{,}760\text{ ms}$ ; Product matrix, $2{,}140\text{ ms}$ ; and Date slicer, $310\text{ ms}$ . The matrix has a DAX query duration of $480\text{ ms}$ and a Visual display duration of $1{,}520\text{ ms}$ .

Which action should you take first to improve the slowest visual?

Optimize the matrix measures because its DAX query accounts for most of the total duration.

Simplify the matrix layout because visual rendering accounts for most of its total duration.

Optimize the regional chart because its query must be slower than the matrix query.

Remove the date slicer because slicers normally cause the other visuals to render slowly.

← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Performance Analyzer

Practice Performance Analyzer in Microsoft Power BI with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Performance Analyzer, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Which action should you take first to improve the slowest visual?

Optimize the matrix measures because its DAX query accounts for most of the total duration.
Simplify the matrix layout because visual rendering accounts for most of its total duration. (correct answer)
Optimize the regional chart because its query must be slower than the matrix query.
Remove the date slicer because slicers normally cause the other visuals to render slowly.

Explanation: When you use Performance Analyzer in Power BI, each visual's total duration breaks down into three components: DAX query time (how long the data engine takes to compute results), Visual display time (how long the rendering engine takes to draw the result), and sometimes a third component for other processing. Your optimization strategy should target whichever component dominates the total — because that's where improvement will have the greatest impact. The Product matrix is clearly the slowest visual at

2{,}140\text{ ms}

. Breaking that down: DAX query is

480\text{ ms}

and Visual display is

1{,}520\text{ ms}

. Visual display accounts for roughly

71\%

of the total duration, meaning the bottleneck is rendering, not query computation. The right first action is to simplify the matrix layout — reducing rows, columns, or conditional formatting — which targets that dominant rendering cost. That makes B correct. A is wrong because it misreads the data. The DAX query at

480\text{ ms}

is actually the smaller portion of the matrix's total time. Optimizing measures would address the wrong bottleneck. C is wrong because it makes an unsupported assumption. You don't have DAX query duration data for the Revenue by Region chart, so you cannot conclude its query is slower than the matrix's

480\text{ ms}

. Also, the matrix is the slowest visual overall, so it takes priority regardless. D is wrong because slicers don't inherently slow down other visuals through their own rendering. The date slicer at

310\text{ ms}

is actually the fastest element on the page. Study tip: On Performance Analyzer questions, always decompose the slowest visual into its sub-durations before choosing an action — the largest sub-duration tells you where to optimize.

Question 2

Performance Analyzer reports $2{,}300\text{ ms}$ for a chart. Its components are DAX query, $210\text{ ms}$ ; Visual display, $190\text{ ms}$ ; and Other, $1{,}900\text{ ms}$ . Several other visuals are also refreshing on the page.

Which conclusion is best supported by these results?

The chart's DAX measure is the confirmed bottleneck because Other time is included in query execution.
The chart's rendering is the confirmed bottleneck because Other time is included in visual display.
The chart spent substantial time waiting or performing uncategorized work, so it should be retested in context. (correct answer)
The chart has no performance issue because only DAX query and Visual display contribute to total duration.

Explanation: When analyzing Performance Analyzer results in Power BI, you need to understand what each timing category actually measures — and what it doesn't explain. DAX query captures query execution time, Visual display captures rendering time, and Other is a catch-all for uncategorized work, which commonly includes time a visual spends waiting while other visuals on the same page are also refreshing. In this scenario, the total is

2{,}300\text{ ms}

, but DAX query (

210\text{ ms}

) and Visual display (

190\text{ ms}

) together account for only

400\text{ ms}

. That leaves Other at $1{,}900\text{ ms}$ — over 82% of the total duration. Since the page has several other visuals refreshing simultaneously, this "Other" time likely reflects resource contention or queuing, not a flaw in this chart's DAX or rendering. The right move is to retest the visual in isolation before drawing conclusions. That reasoning confirms C as the best answer. A is wrong because "Other" time is not part of DAX query execution — it's a separate, uncategorized bucket. Attributing it to the measure is a misreading of what Performance Analyzer reports. B makes the same structural error in the opposite direction: "Other" is not included in Visual display time, so you cannot blame rendering. D is wrong in the other direction — it dismisses the massive "Other" component entirely, which would mean ignoring over 80% of the chart's total load time. As a study tip, remember: whenever "Other" dominates a Performance Analyzer result, treat it as inconclusive rather than a confirmed bottleneck. Always retest the visual in isolation before optimizing.

Question 3

A visual takes $3{,}400\text{ ms}$ during the first Performance Analyzer recording and $620\text{ ms}$ when refreshed immediately afterward. No report or model changes were made between the recordings.

What should you do before concluding that the visual normally completes in $620\text{ ms}$ ?

Use only the second result because Performance Analyzer discards incomplete work during the first recording.
Repeat controlled recordings because caching can make later executions faster than an initial execution. (correct answer)
Add the two durations because the first refresh prepares the visual for the second refresh.
Use only the first result because every later recording measures visual display but excludes DAX execution.

Explanation: Whenever you analyze Performance Analyzer results in Power BI, you need to account for how caching affects timing. Power BI and the underlying engine (Analysis Services / VertiPaq) cache query results and data in memory. This means the first execution of a visual must load data from scratch, while subsequent executions can pull from cache — producing artificially fast results that don't reflect typical real-world performance. In the scenario, the drop from

3{,}400\text{ ms}

620\text{ ms}

is a classic caching signature, not a true performance baseline. Before concluding that

620\text{ ms}

is the normal completion time, you should run multiple controlled recordings — clearing the cache between runs where appropriate — to understand the full performance picture. That's exactly what B recommends, making it correct. A is wrong because Performance Analyzer does not discard incomplete work during a first recording — it captures all activity faithfully. The first result is valid data; the problem is what caused the difference, not data quality. C is wrong because you never add the two durations together. The recordings are independent measurements, not sequential phases of a single process. Summing them has no analytical meaning. D is wrong because later recordings do not exclude DAX execution. Performance Analyzer always breaks down time into DAX query, visual display, and other categories for every recording, regardless of order. As a study tip: on Power BI performance questions, always ask "could caching explain this difference?" A dramatic speedup between back-to-back recordings almost always points to cache, not a genuine improvement.

Question 4

Performance Analyzer shows that a table visual has a DAX query duration of $2{,}600\text{ ms}$ and a Visual display duration of $170\text{ ms}$ . You want to investigate the query outside the report canvas.

Which Performance Analyzer action provides the most relevant artifact for the investigation?

Use Copy query for the visual and analyze the copied DAX query with an appropriate query tool. (correct answer)
Use Export to convert the visual's displayed rows into a normalized semantic model table.
Use Refresh visuals to copy the visual's rendering instructions into the system clipboard.
Use Clear to remove the visual and reveal the model query generated before recording started.

Explanation: When Performance Analyzer reveals a slow DAX query, your investigation should move outside Power BI Desktop into a dedicated query tool — such as DAX Studio — where you can examine execution plans, server timings, and query rewrites. The key artifact you need for that investigation is the actual DAX query text generated by the visual. That's exactly what Copy query (answer A) provides. It copies the complete DAX query — including any measures, filters, and context transitions — directly to your clipboard, ready to paste into DAX Studio or the XMLA endpoint. Since the bottleneck here is the DAX query duration (

2{,}600\text{ ms}

), not the visual render (

170\text{ ms}

), examining and optimizing this query is precisely the right move. B is wrong because Export downloads the visual's result data as a file (e.g., CSV or Excel) — it gives you rows of values, not the DAX query that produced them. You can't paste exported data into a query analyzer to study engine behavior. C is wrong because Refresh visuals simply reruns the visuals to update their data; it doesn't copy anything to the clipboard or produce a query artifact for external analysis. D is wrong because Clear resets the recorded Performance Analyzer log — it discards data rather than revealing or extracting any query. Nothing is copied or exported. Study tip: On Power BI exam questions about Performance Analyzer, always match the bottleneck type to the tool. High DAX duration → use Copy query → analyze in DAX Studio. High Visual display → investigate rendering/formatting instead.

Question 5

Two visuals display the same measure with identical filter context. A card completes in $180\text{ ms}$ . A matrix completes in $2{,}050\text{ ms}$ and displays thousands of cells with conditional formatting. The matrix's DAX query duration is $240\text{ ms}$ .

Which change is the most appropriate first optimization based on the Performance Analyzer evidence?

Rewrite the shared measure because the card proves that conditional formatting increases DAX query duration.
Reduce matrix detail and formatting because the query is short relative to the matrix's total duration. (correct answer)
Replace the card because its low total duration indicates that it bypasses semantic-model security.
Add more matrix measures because additional queries can distribute rendering work across visual threads.

Explanation: When troubleshooting slow visuals in Power BI, the Performance Analyzer breaks total visual duration into three components: DAX query time, visual rendering time, and "other" overhead. The key diagnostic skill is identifying which component dominates — because the fix differs entirely depending on the bottleneck. Here, the matrix takes

2{,}050\text{ ms}

total but only

240\text{ ms}

on the DAX query itself. That means roughly

1{,}810\text{ ms}

— nearly 90% of the total — is consumed by rendering. Thousands of cells plus conditional formatting are classic rendering bottlenecks, not query bottlenecks. The right intervention is therefore to reduce visual complexity: fewer rows/columns, less aggressive conditional formatting, or pagination. That's exactly what B recommends, making it the correct answer. A is wrong because it misreads the evidence. The card's fast completion (

180\text{ ms}

) simply reflects that a single-cell visual has minimal rendering overhead — it says nothing about whether conditional formatting inflates DAX. The DAX measure itself is already proven fast at

240\text{ ms}

, so rewriting it wastes effort. C invents a security concern that has no basis in Performance Analyzer data. A low total duration for a card just means it's a lightweight visual — this has no relationship to row-level security or model access. D is a fabrication. Adding more measures increases query load; it does not distribute or reduce rendering work. Visual rendering is single-threaded per visual, so more queries only add overhead. Study tip: On Performance Analyzer questions, always calculate the rendering gap (total minus DAX duration). If rendering dominates, the fix is visual simplification — not DAX optimization.

Question 6

A chart's total duration is $2{,}800\text{ ms}$ . Performance Analyzer attributes $2{,}350\text{ ms}$ to DAX query and $160\text{ ms}$ to Visual display. The chart contains only five data points.

Which investigation should have the highest priority?

Ignore the visual because a small number of data points guarantees that its total duration is acceptable.
Reduce the chart to three data points because the measured Visual display duration is the dominant component.
Change the chart theme because formatting controls determine the duration of the generated DAX query.
Examine the measures, filter context, and model relationships that contribute to the generated DAX query. (correct answer)

Explanation: When you see a Performance Analyzer breakdown in Power BI, your first job is to identify which component consumes the most time, then investigate why that component is slow. Think of it as a triage system: the largest cost deserves the most urgent attention. Here, the total duration is

2{,}800\text{ ms}

, and the DAX query accounts for

2{,}350\text{ ms}

— roughly

84\%

of the total. That immediately points you toward the data engine, not the rendering layer. The correct path, answer D, is to examine the measures, filter context, and model relationships driving that query. Slow DAX is almost always caused by poorly written measures, expensive filter propagation, or inefficient relationships — all things you can investigate and optimize directly. Answer A is wrong because the number of data points on a visual has no bearing on whether the query behind it is efficient. A chart showing five points can still execute a terribly expensive DAX query against millions of rows. Answer B is wrong because Visual display at

160\text{ ms}

is the smallest component, not the dominant one. Reducing data points would address rendering cost, which is already negligible here. Answer C is wrong because chart themes control visual formatting — colors, fonts, borders — and have no influence on DAX query generation or execution time whatsoever. This is a pure misconception about how the rendering and data layers interact. Your study tip: whenever Performance Analyzer shows a lopsided DAX query time, go straight to your measures and model — that's where the fix lives nine times out of ten.

Question 7

A page contains a slicer and six charts. Users report a delay only when they change the slicer selection. A full-page Refresh visuals recording shows acceptable timings.

Which Performance Analyzer workflow best reproduces the reported issue?

Start recording, change the slicer selection, and inspect the visuals triggered by that interaction. (correct answer)
Start recording, refresh the semantic model, and inspect only the slicer's own DAX query.
Stop recording, change the slicer selection, and then start recording after all charts finish.
Clear the recording, disable visual interactions, and refresh only the unaffected charts on the page.

Explanation: When troubleshooting performance in Power BI, your goal is to reproduce the exact user behavior that causes the slowdown, then capture it with Performance Analyzer. The question tells you the delay happens specifically when users change the slicer — not during a general page refresh. That distinction is your compass. Answer A is correct because it mirrors the reported workflow precisely: start recording before the interaction, perform the interaction (changing the slicer), then inspect the visuals that respond to it. Performance Analyzer captures the DAX queries, DirectQuery calls, and render times for every visual that reacts to the slicer change — giving you an accurate picture of where the delay originates. B is wrong because refreshing the semantic model is a completely different operation than a slicer interaction. It also narrows focus to the slicer's own DAX query, but the slicer itself rarely has a costly query — the six downstream charts do. C is a classic trap: starting the recording after the charts finish means you capture nothing useful. Performance Analyzer must be recording before the triggering action to log the resulting queries and render times. D is wrong on two levels. Disabling visual interactions would prevent the slicer from affecting the charts — eliminating the very behavior you're trying to diagnose. Refreshing only unaffected charts adds no diagnostic value. Study tip: On Power BI performance questions, always ask "does this workflow capture the exact user action causing the problem, with recording active before that action fires?" If the answer is no, the option is a distractor.

Question 8

A report page is already open in Power BI Desktop. You open Performance Analyzer and select Start recording. No entries appear in the pane, even after you wait several seconds.

What should you do to obtain a comparable timing entry for every visual currently displayed on the page?

Select Refresh visuals in Performance Analyzer while recording remains active. (correct answer)
Select Stop recording, close the pane, and reopen Performance Analyzer.
Refresh the semantic model from the Home ribbon while recording remains active.
Save and reopen the PBIX file after enabling background data previews.

Explanation: When working with Performance Analyzer in Power BI Desktop, it's important to understand when it captures timing data. The tool records render times for visuals as they execute queries — but it only captures visuals that actually refresh while recording is active. If a report page was already fully loaded before you clicked Start recording, those visuals have already finished rendering and won't automatically log any entries. This is exactly the scenario described in the question. The page was open and its visuals were already rendered before recording began, so the pane sits empty. The fix is A: select Refresh visuals inside the Performance Analyzer pane while recording is still active. This forces every visual on the page to re-execute its queries, and Performance Analyzer captures a timing entry for each one — giving you a complete, comparable benchmark for the entire page. Option B is wrong because stopping and reopening Performance Analyzer doesn't force a visual refresh; you'd be back in the same situation with an empty pane unless you trigger a refresh separately. Option C is tempting but misleading — refreshing the semantic model from the Home ribbon updates the underlying data source, which is a very different operation from re-rendering page visuals; it also isn't the intended workflow for performance benchmarking. Option D is simply not a real troubleshooting step for Performance Analyzer; saving and reopening the file introduces unnecessary steps and doesn't address the core issue. A good study tip: remember that Performance Analyzer is event-driven — it only logs what happens after you hit Start. If nothing happens, you need to make something happen, and Refresh visuals is the built-in button designed exactly for that purpose.

Question 9

A developer must send a colleague the current Performance Analyzer measurements for several visuals. The colleague needs the recorded categories and durations for offline comparison, not the underlying report data.

Which action should the developer take?

Save the PBIX after clearing Performance Analyzer because the measurements become report metadata.
Export summarized data from each visual and merge the resulting business-data files.
Copy one visual's DAX query because it includes every visual's recorded duration categories.
Export the Performance Analyzer results and share the resulting performance-data file. (correct answer)

Explanation: When working with Power BI's Performance Analyzer, it helps to distinguish between two completely different types of output: performance diagnostic data (timing and rendering metrics) versus business data (the actual dataset values powering your visuals). Questions like this test whether you know the right tool for each purpose. Performance Analyzer has a dedicated Export button that writes all recorded measurements — visual names, DAX query durations, visual display times, and other rendering categories — to a JSON file. This file is purpose-built for sharing diagnostic results offline, which is exactly what the colleague needs. Option D describes this workflow precisely, making it the correct answer. Option A is a trap based on a misconception — Performance Analyzer measurements are session-level diagnostics, not report metadata that gets saved into the PBIX file. Saving the file after clearing the analyzer would actually discard the measurements, not preserve them. Option B confuses performance data with business data. Exporting summarized data from each visual (via the visual's context menu) extracts the underlying dataset values — sales figures, counts, categories — which is entirely unrelated to recording how long visuals took to render. Option C misunderstands what copying a DAX query does. Copying one visual's query from Performance Analyzer gives you that single visual's DAX statement for debugging purposes. It does not bundle every visual's recorded timing durations into a single shareable document. A useful study tip: on Power BI exam questions, whenever you see "send diagnostics" or "share performance measurements," think Performance Analyzer → Export. That export action is the only native way to produce a portable, shareable file of rendering durations.

Question 10

After a page refresh, Performance Analyzer lists one chart at $1{,}900\text{ ms}$ . After the developer removes that chart, another chart that previously showed $1{,}400\text{ ms}$ now completes in $650\text{ ms}$ . The second chart's DAX expression was not changed.

What is the most defensible interpretation of these results?

The removed chart had permanently altered the second chart's DAX expression until it was deleted.
Performance Analyzer always assigns one visual's DAX duration to the next visual in the pane.
Concurrent visual activity may have affected the earlier timing, so page context should be considered. (correct answer)
Deleting any visual automatically optimizes every remaining measure in the semantic model.

Explanation: When you see Performance Analyzer timing questions, think about page-level rendering context — Power BI evaluates visuals concurrently during a page refresh, meaning each visual's execution time is influenced by shared engine resources, query parallelism, and memory pressure caused by other visuals running simultaneously. That framing makes C the most defensible interpretation. The second chart's drop from

1{,}400\text{ ms}

650\text{ ms}

— with no DAX changes — strongly suggests that the removed chart (at

1{,}900\text{ ms}

) was competing for engine resources during the original refresh. Once that expensive visual was eliminated, the second chart had more headroom and completed faster. The timing difference reflects environmental context, not a change to the measure itself. A is wrong because deleting a visual cannot retroactively or persistently alter another visual's DAX expression. DAX expressions are stored definitions — one visual has no write access to another's measure logic. B describes a fabricated behavior. Performance Analyzer does not redistribute or reassign DAX durations between visuals in a sequential or mechanical way; each visual's reported time reflects its own query execution as observed. D is wrong because deleting a visual triggers no optimization of remaining measures in the semantic model. Measures are not recompiled or restructured by removing an unrelated visual from a report page. Study tip: On Power BI exam questions involving Performance Analyzer, always consider the full page context. A single visual's timing is not guaranteed to be stable in isolation — concurrent rendering, model caching, and resource contention all influence results. Never treat one timing reading as an absolute benchmark.