Very slow performance in TI using ViewZeroOut function

[hugzer77]

Hello everyone,

I am currently working on a TI process to clean data from my cube over a given period. To do this, I use the ViewZeroOut function after having specified the view I want to clean.
Basically, I take all the N levels of my dimensions with the exception of the period function, where I take a specific value, which is also at leaf level -> every dimension subset is created by MDX and temporary, rendered static with the MDX set to empty through SubsetMDXSet( DimName , SubsetName, '')

Besides, I set the three extract conditions to 1 :
ViewExtractSkipCalcsSet ( CubeName , vSourceView ,1);
ViewExtractSkipZeroesSet ( CubeName , vSourceView ,1);
ViewExtractSkipRuleValuesSet ( CubeName , vSourceView ,1);

And then, I use the ViewZeroOut function on the view I just created.
This is when the ViewZeroOut takes three minutes to compile on its own and I don't understand why it does take that long (it takes less than 1 second if I comment the function). Can someone please relate from a similar problem or can explain me how does the ViewZeroOut work ?

I hope I've made my message clear.
Thanks in avance

[Elessar]

Hi,

Is there a possibility that it is really a huge view and it should take so much time?
Have you switched Logging OFF temporary before zeroing out?

[gtonkin]

Hi,
Cannot see any need to use any of the ViewExtractSkip functions on a zero out.
Making the sets static as you explained is always a good idea where the view is a datasource.

Have you turned off logging or do you need it on?

Anything that could be causing this like intercube feeders and other rules?

[lotsaram]

Try using bedrock.cube.data.clear for the same cube area and see if it is faster.

[hugzer77]

Hi all,

Thank you for your replies.

Hi,

Is there a possibility that it is really a huge view and it should take so much time?
Have you switched Logging OFF temporary before zeroing out?

It is a huge view but it should not take that much time. I have a similar cube and it takes around 1 second to execute so I expected a similar behavior here. The logging is always OFF for the cube I am working with.

Hi,
Cannot see any need to use any of the ViewExtractSkip functions on a zero out.
Making the sets static as you explained is always a good idea where the view is a datasource.

Have you turned off logging or do you need it on?

Anything that could be causing this like intercube feeders and other rules?

Okay I just deleted the ViewExtractSkip functions but nothing changed. I also tried to temporarily delete the rules but once again, it did not change anything.

Try using bedrock.cube.data.clear for the same cube area and see if it is faster.

Maybe, I should try this, thank you.

[Steve Rowe]

Perhaps check out the dimension ordering versus the cube that is performing well?

[hugzer77]

Perhaps check out the dimension ordering versus the cube that is performing well?

You may be right. The cube which is performing well has this kind of order : Product, Period, Season, Version, Measure.
On the other hand, the cube with the slow performance looks like Version, Season, Product, Period, Measure (approximately).
At first, we wanted this cube to have the same dimensions order than the other one but it would consume too much memory so we followed the dimension reordering recommendation suggested by TM1 (through Architect) and we obtained the result above and saved a significant amount of memory.

Can dimensions reordering cause latency in such processes ? Even for the easiest case of cleaning data with a ViewZeroOut ?

[Wim Gielis]

This is strange behavior. What does the }Stats cubes say about number of data points and similar measures? Did someone inflate the number of cells from data input at very high level ? Stet function in the rules or other things ?