This tutorial will discuss about CallBackDataID, which is a performance issue in DAX Studio. You’ll learn what it does and how it affects the performance of your DAX query.
The storage engine works to provide data to the formula engine in the form of a data cache. But when the storage engine is unable to evaluate an expression, it asks and calls back the formula engine for help using the CallBackDataID.
Having a CallBackDataID in your calculation slows down the performance of DAX because it uses both the storage and formula engine. However, it’s still better than having only the formula engine do all the work because it still performs on a compressed data and won’t require materialization.
Also, when the formula engine is involved, the results are not cached. Caches improve the user experience in running a query or measure in Power BI.
Where To Find The CallBackDataID
CallBackDataID can be found in the Server Timings inside DAX Studio. Because of their importance, they are highlighted in the xmSQL statement. When you’re looking to optimize your DAX, finding the CallBackDataID is the best place to start.
Another optimization technique is to leverage the filters in CALCULATE whenever possible. Using CALCULATE in the filters is better than using FILTER as a table. FILTER is an iterator and when you filter a table, it’s going to be iterated by SUMX. The presence of these two iterators could slow down your query.
Here are two sample queries with and without the CallBackDataID.
This is a localized measure that defines the two queries above.
The top measure iterates the Sales Table, multiplies the Current Price and Quantity, and then sums it up. The bottom measure checks if the Purchase Date is greater than or equal to March 31, 2016. Having an IF function in a measure creates a CallBackDataID because it’s not using CALCULATE.
To test this, run the query that has the CallBackDataID. Make sure to clear the cache and turn the Server Timings and Query Plans on before you run it.
If you click the Server Timings tab at the bottom, you can see that the first scan is highlighted. This is because of the presence of the CallBackDataID.
You can also see the CallBackDataID in the xmSQL statement. The IF function in the measure is beyond the storage engine’s capabilities so it asks for help from the formula engine.
How To Solve The Performance Issue
If you run the query that doesn’t have a CallBackDataID, you can see that the scans are no longer highlighted.
This is because the CALCULATE filter is being pushed down to the storage engine. It doesn’t need help from the formula engine anymore because it can work by itself.
As much as possible, try to use filters in CALCULATE. It optimizes DAX performance by pushing most of the work into the storage engine, making it faster.
***** Related Links *****
Storage Engine In Power BI – VertiPaq Operators & Queries
Measure In Power BI: Optimization Tips And Techniques
VertiPaq Analyzer In DAX Studio | Power BI Tutorial
Conclusion
Performance hits may arise if your query is too complex for the storage engine to work. It brings unnecessary processes like the CallBackDataID in the calculation and slows down your DAX. You can mitigate it by using filters in CALCULATE.
Nick
