Slow calc time with SET CREATEBLOCKONEQ OFF for block creation

Question

Hello everyone,
I have a problem with the slow execution of one of my calc scripts:
A simplified version of my calc script to calculate 6 accounts looks like this:
SET UPDATECALC OFF;
SET FRMLBOTTOMUP ON;
SET CREATEBLOCKONEQ ON;
SET CREATENONMISSINGBLK ON;
FIX (
FY12,
"Forecast",
"Final",
@LEVMBRS("Cost Centre",0),
@LEVMBRS("Products",0),
@LEVMBRS("Entities",0)
SET CREATEBLOCKONEQ OFF;
"10000";"20000";"30000";"40000";"50000";"60000";
SET CREATEBLOCKONEQ ON;
ENDFIX
The member formula for each of the accounts is realtively complex. One of the changes recently implemented for the FIX was openin up the cost center dimension. Since then the calculation runs much slower (>1h). If I change the setting to SET CREATEBLOCKONEQ ON, the calculation is very fast (1 min). However, no blocks are created. I am looking for a way to create the required blocks, calculate the member formulas but to decrease calc time. Does anybody have any idea what to improve?
Thanks for your input
p.s. DataStorage in the member properties for the above accounts is Never Share

Answer 1

MattRollings wrote:
If the formula is too complex it tends not to aggregate properly, especially when using ratios in calculations. Using stored members with member formulas I have found is much faster, efficient, and less prone to agg issues - especially in Workforce type apps.We were experiencing that exact problem, hence stored members^^^So why not break it up into steps? Step 1, force the calculation of the lower level member formulas, whatever they are. Make sure that that works. Then take the upper level members (whatever they are) and make them dynamic. There's nothing that says that you must make them all stored. I try, wherever possible, to make as much dynamic as possible. As I wrote, sometimes I can't for calc order reasons, but as soon as I get past that I let the "free" dense dynamic calcs happen wherever I can. Yes, the number of blocks touched is the same (maybe), but it is still worth a shot.
Also, you mentioned in your original post that the introduction of the FIX slowed things down. That seems counter-intuitive from a block count perspective. Does your FIX really select all level zero members in all dimensions?
Last thought on this somewhat overactive thread (you are getting a lot of advice, who knows, maybe some of it is good ;) ) -- have you tried flipping the member calcs on their heads, i.e., take what is an Accounts calc and make it a Forecast calc with cross-dims to match? You would have different, but maybe more managable block creation issues at that point.
Regards,
Cameron Lackpour