Why placing a system module boolean in the main module helps improve performance? (Daisy Chain)

Hello,
I have a situation where it feels like the daisy chaining is somehow improving the performance instead?

I'll elaborate further below-

Context: User enables a calc by selecting a checkbox. If not enabled, the result is 0 to give an early exit to the formula.

Approach 1 : Refer to the SYS Users module in the IF statement as below-

This takes 3.05% calc effort

Approach 2 : Add the selector users boolean in this module against all dimensions-

Then refer to this in the main formula-

In this case it takes 0.48% + 1.92 (Check line item) = 2.4% as against the 3% in approach 1

Moreover, I am using this check in 4-5 line items so there the cumulative reduction adds up quite significantly from each line being 2% to 0.5%.

Any insights on why this happens? I'd believe referring to the system module should have been more efficient since the boolean only applies to user dimension.

Accepted answers

Kanishq17

it can be possible that dimension of source reference is of entire user list compared to this module which has a subset so effort may take in that manner

All comments

Kanishq17

it can be possible that dimension of source reference is of entire user list compared to this module which has a subset so effort may take in that manner

devrathahuja

@Kanishq17 - Yes you're correct. It was the difference between subset & the main list which caused such a big difference in the calc effort!

Thanks for the spot! :)

kjacokes

Even if you account for the fact you're using a subset, your observation remains true.

My understanding of the reason of this has to do with sparse and dense dimensions. While I very much don't miss working with Essbase, and find Anaplan to be the superior platform, this is a pretty good illustration of a technology-agnostic concept of sparse and dense dimensions.

https://docs.oracle.com/en/database/other-databases/essbase/21/essdm/dimensions-and-members.html#GUID-E6E68C8C-BCA1-45CA-B09F-3D829163FACE

In Anaplan terms, think of Time, Versions, and Line Items (specific to a given module) as being your dense dimensions.

For that reason calculations within those dimensions will inherently be faster.

As soon as you introduce a sparse dimension (i.e., any "General List" OR reference a line item outside of your module), you're effectively accessing a different block, and therefore there's some incremental overhead the model must perform.

This is all wild speculation, and I would welcome someone correcting me, but this has proved a good enough working idea of the underpinnings of Anaplan based on a couple of decades working with multi-dimensional databases.

kjacokes

deleted duplicate post.

devrathahuja

@kjacokes - Thanks for the explanation. While I do agree there could be the possibility that the engine requires some extra work on fetching the data from some other module instead of within that module, what was surprising is the % of extra calc effort it took to do that.

I then also played around a bit with this build by switching the order of applies to, and if you use the ellipsis to let Anaplan decide the order of applies to dimension, it moves the user subset at the end and then the performance worsens again.

This could have to do with having the user dimension first and the early exit which makes sense.

And even in the case of fetching a line item from some other module vs the same module, when using the same subset it is able to fetch it from the other module with again considerably low amount of calc effort.

So there is something specific to do with subsets here? Perhaps how Anaplan identifies it or maps it?

Happy to hear more thoughts about this :)

kjacokes

@devrathahuja , ooh great observation, I should’ve thought of that but honestly didn’t.

You’re right that Anaplan reorders the dimensions when you use the ellipsis to update dimensionality of a line item or module, which is a known issue.

And I agree with your observation that order does affect performance, though that’s based more on what I’ve read than personal lived experience. In other words I believe it and understand it in theory I just haven’t played around with it enough to witness large observable differences in speed based on dimension ordering. So what I do is I tend to always build a first draft of a model with full lists, leave the default dimension order in place for consistency, and then when I never use the ellipsis when I introduce subsets, and always edit the text directly, so that the dimension order remains unaffected. That helps avoid issues where the reordering would impact performance.

https://community.anaplan.com/discussion/32934/oeg-best-practice-dimension-order

What I’m not sure of is whether the reordering affected performance because of the lack of consistency of dimension order creating extra overhead due to fewer tasks executing in parallel vs. the dimension order interacting with the formulaic logic to exiting the calculation earlier with one of the dimension orders thereby avoiding unnecessary tasks altogether vs. some combination of the above.

I actually have a handful of high-effort calcs across a handful of models that I’ve bookmarked to revisit after budget season, and this sounds like a good time to revisit these.

I scheduled some fact-finding and analysis time for later this week and will circle back here with any additional data points I can offer.

In the interim, let me know if you have any other thoughts or if anything I’ve shared above does / doesn’t sync with what you’ve observed?

devrathahuja

@kjacokes - Yes makes sense. Thanks for sharing the article, I just went through it again & realised that in case of subsets/LIS we should manually update the order. I had noticed that Anaplan puts all general lists first & then subsets/LIS but thought that was because that's how the optimal order should be.

With regards to noticing change in performance due to the order of applies to, I have noticed it also in case of text concatenations. Having the formula and the applies to order aligned has reduced the % calc effort by half as well.

I believe it'd have to do with the engine having to find the right order & then execute vs just execute (As also shown in the diagram with the diagonal mappings vs 1:1 mapping). Something similar to how in excel if you had your rows the same in 2 sheets you'd just write A1 x B1, but if the order was not the same we'd have to add an additional Vlookup/Index/Match to align that first. That's my theory at least!

Good luck with the optimization activity & do share anything interesting you come across! :)

Quick Links

Can you help?

Unanswered questions

Module Information Visibility Restricted for Non‑Admin Users on Anaplan page
Why are non‑admin users unable to view Module information on the Anaplan page, while workspace administrators can? (After click the three dots on the grids right up corner) Are there any configuration options that allow non‑admin users to view module details without granting full workspace administrator access?
How to synchronize scroll a card/s from the main board and another card/s in the insights panel?
Just like the main question above, I wanted to try out the new feature on the board where you can you the insights panel to put additional cards. However, I wanted to synchronize scroll a card on the main board with the card on the insights panel but I can't find where it might be.
ADO connection from postgreSQL
Hi everyone, I am trying to create a connection ADO from PostgreSQL, but I consistently receive the following error: Failed to establish a connection The following message was sent from the target system: The SSL certificate is either invalid or not in unencrypted PEM format. Please check your certificate and try again.…