Measure Killer Measure Killer

These docs are still being polished — a few sections and screenshots are on the way. Spotted something off? Let us know.

Performance & optimization — find what's slowing you down

Identify slow reports, bloated models, and best-practice violations across your Power BI tenant. Combine load times, model size, used/unused analysis, and best practices to prioritize what to fix.

What Measure Killer covers

Measure Killer gives you five angles on performance — each one answering a different “why is this slow?” or “where should I optimize?” question.

Report load times — which reports are slow?

The Average load time column shows how long each report takes to fully render, averaged per user, in seconds. Reports consistently above 5–10 seconds are worth investigating.

Load times accumulate in a local SQLite database across scans, so you can track whether a report is getting slower or faster over time — and measure the impact of optimization work.

Report load times

Model size & used/unused analysis — is the model bloated?

The Semantic models tab shows the in-memory size of every model, and after running the used/unused analysis, a % unused figure and estimated size that can be freed.

A model that’s 60% unused is carrying columns and measures that nothing references — they inflate refresh times, memory consumption, and capacity cost for no benefit. Removing them shrinks the model and speeds up everything downstream.

Find and remove unused measures and columns | Semantic models inventory

Best-practice analysis — what anti-patterns exist?

Measure Killer runs best-practice rules at two levels:

Model best practices — flag anti-patterns in the semantic model: deeply nested DAX, missing aggregations, oversized columns, auto-date/time tables, unused calculation groups.

Report best practices — flag issues in the report layer: too many visuals per page, implicit measures, unused custom visuals, oversized report-level measures.

Both sets of rules have adjustable thresholds and can be individually enabled or disabled. The findings often explain why a report is slow — too many visuals, heavy report-level DAX, or a model that triggers unnecessary calculations.

Best-practice analysis

Storage mode — Import, DirectQuery, or Direct Lake?

The Storage mode column on the Semantic models tab shows whether each model uses Import, DirectQuery, Dual, or Direct Lake. This is important context for performance:

  • Import models load data into memory — slow load times usually mean the model is too large (remove unused columns) or DAX is heavy.
  • DirectQuery and Dual models query the source system at render time — slow load times may be the source system, not the model.
  • Direct Lake reads from OneLake — performance depends on file layout, V-Order, and whether the engine falls back to DirectQuery.

Semantic models inventory

Capacity metrics — what is it actually costing?

The Capacity metrics window breaks down Capacity Unit (CU) consumption per capacity, workspace, item type, item, and operation, with 24h and 7-day trend arrows. Sort by Total CU to surface your most expensive items, or by % change to catch a runaway cost early — then drill to the operation level to see why something is expensive.

This is what turns “this model is slow” into “this model is consuming the most CUs, and it’s a background refresh driving it” — the link between performance work and the actual capacity bill.

Capacity metrics

A typical optimization workflow

  1. Start with load times. Sort the Power BI reports tab by Average load time (descending) to find the slowest reports.
  2. Prioritize by usage. Cross-reference with report views & opens — a slow report with 500 weekly views is a higher priority than one nobody opens.
  3. Check report best practices. Too many visuals per page, implicit measures, and other report-level issues are the easiest wins — they don’t require model changes.
  4. Drill into the model. Check the connected semantic model’s size, % unused, and storage mode. If it’s Import and 50%+ unused, removing dead columns will shrink it significantly.
  5. Check model best practices. Anti-patterns like auto-date/time tables, deeply nested DAX, or unnecessary bi-directional relationships add hidden cost.
  6. Clean and measure. Use Clean your model for guided suggestions, or remove unused objects directly via Clean TMDL, Kill DAX, or 1-click XMLA removal. Run another scan and compare load times — the SQLite history gives you the before-and-after.

Common performance workflows

  • Quarterly performance audit. Sort reports by load time, flag anything above 5 seconds, assign owners for remediation. Re-scan next quarter to track improvement.
  • Pre-migration assessment. Before moving to Fabric or changing capacity tiers, identify the models that consume the most resources. Optimize the biggest offenders first to reduce the capacity you need.
  • Post-optimization validation. After cleaning a model or refactoring a report, compare load times against the baseline in the SQLite history. Quantify the improvement for stakeholders.
  • Capacity cost reduction. Combine model size data with capacity metrics. Models that are large, mostly unused, and rarely queried are prime candidates for cleanup or archival.