Issues management

The analysis of a model can produce a list of issues. Each issue is a part of DAX code with an anti-pattern that could have a negative impact on the performance of the model.

To maximize your productivity, you can use the following approach:

1. Run a model analysis.
2. Evaluate the issues with higher priorities.
3. Fix the issues in the measures affected by high relevance issues
4. Evaluate the performance of critical reports.
5. Repeat the process until you are satisfied with the overall performance.

Reaching a zero-issues state for a model is not the primary goal of DAX Optimizer. The goal is to maximize the performance improvement with the minimal effort of DAX code refactoring. However, if you use DAX Optimizer to keep the model in good shape, then you should keep the model with zero issues by running frequent analyses with DAX Optimizer.

You have different options to evaluate the issues and decide what to do. Indeed, you have a list of issues, but you end up modifying measures. For this reason, you might work issue by issue or measure by measure. DAX Optimizer provides the tool to implement both approaches.

Measures and issues

Each measure can have multiple issues. Each issue has a type and a state:

• The type is the anti-pattern that has been detected.
• The state is the status of the issue: Open, Fixed or Ignored.

You review the issues and decide what to do:

• Fix issue: you fix the issue by changing the DAX code of the measure, and you mark the issue as fixed. You continue to review the other “Open” issues; the fixed ones are hidden by default.
• Ignore issue: you mark the issue as ignored. The ignored issues are hidden by default and you continue to review the other “Open” issues. In the next analysis, the issue state will still be Ignored if the measure has the same fingerprint, or Open if the measure changed.

You evaluate the issues and mark them as fixed or ignored depending on the action you want to take. The state of each issue is saved in the corresponding version of the model analysis on the cloud. When the analysis is executed again, the issues that have been ignored are not reported again if the measure has the same fingerprint.

Analyzing by issue

The Issues tab shows the list of issues in the model.

You can group the issues by type or measure.

The analysis by issue is useful when you want to fix all the measures with similar issues. If time is limited and you want to fix the more expensive measures first, you can use the analysis by measure.

You can also use the analysis by issue to quickly set the state of fixed and ignored issues. The alternative is to use the analysis by measure and set the state of each issue one measure at a time.

Issues not grouped

By default, the visualization is Don’t Group (1): each row on the Issues page shows an issue in a measure. The Occurs column shows a value greater than one only when the same issue is present more than once in the same measure.

This view highlights the more expensive issues faster in individual measures. By clicking on the measure name, the view show all the issues in the selected measure

Issues grouped by type

With Group By Issue (2), each row shows an issue type with the number of measures that have at least one issue of that type.

Issues grouped by measure

With Group By Measure (4), each row shows a measure with the number of issue types found in the measure. By expanding the measure (5), you see the number of occurrences of each issue type in the measure.

Measures by issue type

When you select an issue type, you see the list of measures that have at least one issue of that type.

If you click Fixed or Ignored on a measure, all the issues of the same type for that measure are marked as Fixed or Ignored.

Visualizing measures by issue type is helpful to see the impact of an issue common to many measures. Still, it does not allow marking individual issues in each measure because all the issues of the same type are marked at the same time.

Analyzing by measure

The Measures/KPIs tab shows the list of measures in the model.

Each row shows the status of the measure, the number of issues, and additional metrics to evaluate the importance of the measures from an optimization perspective.

When you click on a measure, you go to the measure visualization that shows all the issues within a measure.

By activating the Expert view (1), you can see additional columns.

Here is the meaning of the columns in the measures list:

• Issues: the number of issues in the measure.
• Relevance: the estimated impact of the measure on the overall performance of the model.
• CPU Opt (expert view): Possible optimization (%) of the CPU cost of the measure.
• CPU Cost (expert view): Estimated CPU cost of the measure inclusive of referenced measures.
• RAM Opt (expert view): Possible optimization (%) of the RAM cost of the measure.
• RAM Cost (expert view): Estimated RAM cost of the measure based on the maximum materialization expected.
• Exec: How many times the measure is executed in the model.
• Dir Ref: The number of measures that have a direct reference to the measure.
• Ind Ref: The number of measures that depends on this measure but do not have a direct reference to it.

You can sort the measures by clicking on the column header. The default sort is by relevance, but you can use different strategies to evaluate how to prioritize the optimization effort.

Sort measures by relevance

The default sort is by relevance, which is an estimation that considers all the factors: direct and indirect references, CPU cost, RAM cost, and executions. This sort is useful when you want to optimize the model by fixing the measures with the highest impact on the overall performance of the model.

Sort measures by CPU cost

The sort by CPU cost (2) helps prioritize measures with a high estimated CPU cost regardless of the related materialization (RAM cost).

The CPU cost is important to evaluate the performance impact of a measure in a report, but it is not the first criterion to select the measure to optimize because the CPU cost could depend on other referenced measures.

A high CPU Cost indicates that a single execution of the measure is expensive.

A measure with a high CPU cost and low relevance is one whose CPU cost probably depends on other referenced measures with a higher relevance.

Sort measures by RAM cost

Sorting by RAM Cost (3) helps prioritize measures with a high estimated RAM cost (materialization) regardless of the related CPU cost.

The RAM cost is important to increase the scalability of a model (number of concurrent users) and to avoid out-of-memory errors during report execution.

A high RAM cost indicates that a single execution of the measures produces a large materialization compared to other measures.

A measure with a high RAM cost and low relevance is one whose RAM cost probably depends on other referenced measures with a higher relevance.

Issues by measure

When you select a measure, you see the list of all the issues in the measure.

If you click Fixed or Ignored on an issue, you mark the specific issue selected. If an issue type has many occurrences in the same measure, you see in the list one row for each occurrence of each issue. By clicking the issue, the user interface highlights the corresponding DAX code in the measure.

Visualizing the issues in the measure controls the issues state with the maximum level of detail because you can mark as Fixed or Ignored each issue occurrence in an independent way.