There are often many available methods of implementing business logic and custom filter contexts into DAX measures. Although these alternatives deliver the essential functional requirements, they can have very different performance characteristics, which can ultimately impact user experience and the scalability of a dataset. When migrating a self-service dataset to a corporate solution or preparing a large and highly utilized dataset, it's always a good practice to test common queries and the DAX measures used by those queries.

For example, the same common dimension grouping (for example, Product Category and Year) and the same filter context (Year = 2018) could produce dramatically different performance results based on the measures used in the query, such as Net Sales versus Count of Customers. The alternative performance statistics associated with different measures such as duration and the count of storage engine queries generated could then be used to focus performance tuning efforts. 

In some cases, the DAX measures associated with slow queries cannot be significantly improved, but the data obtained from the performance testing results can drive other changes. For example, report authors could be advised to only use certain measures in less performance intensive visuals such as Cards, or in reports that have been substantially filtered. In a DirectQuery model, the data source owner of the dataset may be able to implement changes to the specific columns accessed via the slow-performing measures.