Over the past several months, we’ve dedicated significant effort to improving infrastructure and laying the groundwork for more enhancements scheduled later this year. Today, we’re pleased to announce two new features that are now available in DAX Optimizer version 1.4 to examine more DAX expressions in a semantic model:

If you have Tabular Editor 3, download the new release fully integrated with these new features!

Row-Level Security (RLS) filter expressions

In DAX Optimizer 1.4, we now support the analysis of filter expressions used within row-level security roles. This feature evaluates the cost of your security filters, comparing it to the cost of other DAX measures present in your model so that you can evaluate the performance impact.

In this release, the engine detects the same types of issues as those detected in standard DAX measures. For example, this model has two security roles with a filter on the Store table.

The relevance of the Store Manager security filter is much higher than the Manager Optimized role. However, you probably do not have two versions of the same security role in the same model. Therefore, comparing the cost with other more expensive DAX expressions in the model is helpful. The bar chart on the top right of the detailed view compares the RLS filter cost with other expensive model elements.

The tooltip on the first bar shows the actual cost of the RLS filter expression.

The second bar corresponds to the more expensive object in the model (the Sales Amount measure), ignoring the current filter expression.

Thus, the Store Manager RLS filter is more expensive than the most costly measure in the model.

Let’s repeat the same evaluation by considering the second role, Manager Optimized, which has a faster version of DAX expression.

As usual, the simpler, the better. The tooltip clarifies that this RLS filter is less expensive than the Sales Amount measure we previously used as a comparison term.

The relevance of the DAX expression used in RLS filters is accurate; you need some practice to figure out how to rewrite the code by keeping the same semantics, as the documentation of the existing issues is focused on providing examples for DAX code used in measures.

In the coming months, we will add more issue types specific to security filters, covering a much broader number of common bottlenecks and providing more detailed explanations about improving performance in these cases.

Calculation items in calculation groups

Another key addition is our new capability to analyze DAX expressions within calculation items of calculation groups. Due to the dynamic nature of calculation items, whose cost can vary significantly based on the context of their application, DAX Optimizer cannot provide a precise cost estimate, as it shows only the number of issues detected in each calculation item.

Nevertheless, DAX Optimizer offers actionable insights into potential issues without prioritizing them – the impact “0%” should be ignored for the calculation items, as it simply depends on the context where the calculation group will be used.

Our documentation outlines an effective workaround for users seeking more precise estimations when the calculation item is applied to specific measures.