What it does

A recorder in Power BI Desktop that logs how long every visual takes to update when you interact with a report, broken down by DAX query time, rendering time and everything else. It's the first tool to reach for when someone says a report is slow.

Key facts

• Desktop only. There's no Performance Analyzer in the service, so you're profiling against your machine and your connection, not the user's.
• Found on the View ribbon. Start recording, interact with the report, stop, read the log.
• Each visual's entry splits into DAX query (time from the visual issuing the query to Analysis Services returning results), Visual display (drawing, plus fetching web images and geocoding), Other (preparing queries, waiting on other visuals, background work), and Evaluated parameters for field parameters.
• Durations are start-to-end timestamps, and most canvas and visual operations run sequentially on a single UI thread. So a visual's duration includes time spent queued behind other visuals — it is not pure work done.
• Refresh visuals reruns everything on the page. Analyze this visual, on the visual's corner while recording, reruns just that one.
• Export writes the log to a .json file. Clear wipes it with no save.
• The DAX query for any visual can be copied out and opened in DAX query view, where you can run it, define scoped measures with DEFINE MEASURE, and push changes back into the model.
• Schema complexity affects the numbers — table count, relationship complexity and foreign key constraints all show up as initial delay before anything renders.

When to use / skip

Reach for it the moment a performance complaint is specific enough to reproduce. It answers one question well — is this a data problem or a rendering problem — and that single answer redirects most tuning work. Where it stops being useful is anything about the service: capacity load, concurrency, gateway latency, refresh cost. If the report is fast in Desktop and slow in the service, Performance Analyzer has told you what it can and the next stop is the Capacity Metrics app.

Configuration decisions

• Whether you profile against the full production model or a filtered copy — the answer is the full one, since cardinality is usually the problem.
• Whether you're measuring a cold start or a warm one. Do both, deliberately, and label which is which.
• Which interactions you record. A page load and a slicer change are different problems and want separate recordings.
• Whether the export goes into project documentation as a before-and-after baseline, which is what makes tuning work defensible at invoice time.
• Whether findings go to the model (DAX, cardinality, relationships) or to the report (visual count, custom visuals, images).

Gotchas

• The single-threaded queueing means durations are not additive and not independent. A visual showing 4,000 ms may have spent most of it waiting. Look at the shape of the whole log, not one number.
• Long "Other" times usually mean too many visuals on the page rather than anything wrong with any one of them. Fifteen visuals on a page is a design problem that no DAX tuning fixes.
• Custom visuals can dominate Visual display time and there's very little you can do about it beyond replacing them.
• Desktop timings flatter you. Your laptop has no other users on it, and the model may not be under the memory pressure the capacity is.
• Clearing the pane is unrecoverable. Export first if the recording took any effort to produce.

Consultant notes

• Take a Performance Analyzer baseline before you start optimisation work and export it. Being able to show "page load 9 seconds, now 2" is worth more to the client than the fix itself.
• The DAX-versus-render split is the thing to explain to the client. It reframes "Power BI is slow" into two different conversations with two different owners.
• Push back gently on report pages with a dozen visuals. Consumers ask for them and then complain about the load time, and it's easier to have that conversation with a log in your hand.
• If Desktop is fast and the service is slow, say so early and move the investigation to capacity rather than spending another week on DAX.

---

Worth another look if the Analyzer gains service-side profiling, or after any change to the DAX query view integration.