The Member Formula
NONEMPTYTUPLE ([Units], [MTD])
Sum(
{
ClosingPeriod(Time.Generations(5), Time.CurrentMember),
Time.CurrentMember.Lag(1),
Time.CurrentMember.Lag(2)
},
Units
)
The Tests
In this test I will duplicate the data pull that I used in Part 1 by zooming to the bottom on the Store Manager and Stores dimensions with the month of March selected. These are the four tests. Each retrieval will be identical.1. Run the example as is, including the NONEMPTYTUPLE statement.
2. Remove the NONEMPTYTUPLE statement.
3. Change the NONEMPTYTUPLE ([Units],[MTD]) to NONEMPTYMEMBER [Units]
4. Change the NONEMPTYTUPLE ([Units],[MTD]) to NONEMPTYMEMBER [MTD]
The query time results are below. Each returned the exact same set.
The Results
1. 0.39s2. 9.72s
3. 0.29s
4. 9.7s
Note: I got the same warning in the log for the 3 Month Units member as I got in Part 1 during the MDX query execution for Test 4.
Warning: Non empty member directive [MTD] for member [3 Month Units] will be ignored since it is from a different dimension.
Analysis and Conclusions and Another Test
These results were almost exactly in line with the results in Part 1. They were all +.07 or +.08 the respective test in Part 1, the difference probably attributed to overhead/network latency associated with Smart View. The non-empty directive can help ASO member formulas. I wondered if it had something to do with the fact that an attribute dimension (Store Manager) was used in the query. So I removed that and reran the test.
1. 0.34s
2. 0.39s
3. 0.24s
4. 0.38s
2. 0.39s
3. 0.24s
4. 0.38s
It looks like the attribute dimension was hurting the performance when not using the non-empty directive. The difference in performance without the attribute dimension is very minor but there still is a difference albeit very small. The bottom line is that you should probably at least try to use the NONEMPTYMEMBER and NONEMPTYTUPLE when the application log suggests it.
No comments:
Post a Comment