TM1 Forum

We got 2 big cubes,just named them cubeA & cubeB
cubeA's size is 23.04G, while cubeB's size is 18.41G.
cubeB has 6 dimensions in order for example:a,b,c,d,e,f.
cubeA has 7 dimensions a,b,c,d,e,f,g.

My question,it's so strange that when we load cubeB, it will cost about 20+G memory, however, when we load cubeA, it will terribly cost more than 60+G,or even 70+G. I am confused because the new dimension named g in cubeA is just a small dimension with only one element.

May I beg your help to give some suggestion? Any solusion to this terrible huge memory usage problem will be appreciated.

Thanks and regards,
Walter

wuruimao wrote:We got 2 big cubes,just named them cubeA & cubeB
cubeA's size is 23.04G, while cubeB's size is 18.41G.
cubeB has 6 dimensions in order for example:a,b,c,d,e,f.
cubeA has 7 dimensions a,b,c,d,e,f,g.

My question,it's so strange that when we load cubeB, it will cost about 20+G memory, however, when we load cubeA, it will terribly cost more than 60+G,or even 70+G. I am confused because the new dimension named g in cubeA is just a small dimension with only one element.

May I beg your help to give some suggestion? Any solusion to this terrible huge memory usage problem will be appreciated.

Dimension order can make a huge difference to memory usage. As discussed in this thread, small dimensions should, as a rule of thumb, always go before large ones. I'd try reordering your dimensions in your development system; you'll almost certainly find a better dimension order with some trial and error.

That having been said... I'm not sure that I see the point of having a dimension with only one element. Every value will be stored against that single element which would appear to make it redundant.

Alan Kirk wrote:

wuruimao wrote:We got 2 big cubes,just named them cubeA & cubeB
cubeA's size is 23.04G, while cubeB's size is 18.41G.
cubeB has 6 dimensions in order for example:a,b,c,d,e,f.
cubeA has 7 dimensions a,b,c,d,e,f,g.

My question,it's so strange that when we load cubeB, it will cost about 20+G memory, however, when we load cubeA, it will terribly cost more than 60+G,or even 70+G. I am confused because the new dimension named g in cubeA is just a small dimension with only one element.

May I beg your help to give some suggestion? Any solusion to this terrible huge memory usage problem will be appreciated.

Dimension order can make a huge difference to memory usage. As discussed in this thread, small dimensions should, as a rule of thumb, always go before large ones. I'd try reordering your dimensions in your development system; you'll almost certainly find a better dimension order with some trial and error.

That having been said... I'm not sure that I see the point of having a dimension with only one element. Every value will be stored against that single element which would appear to make it redundant.

Thank you for your opinion very much.

Yes I am trying to reorder the dimensions and test the memory usage. It will take much time to test once. Actually i should reorder dimensions to make the small ones gone before large ones.
For the dimension with only one element, I think it's for the easy extention of our product.Actually it make sense.

wuruimao wrote:

Alan Kirk wrote: That having been said... I'm not sure that I see the point of having a dimension with only one element. Every value will be stored against that single element which would appear to make it redundant.

Thank you for your opinion very much.

Yes I am trying to reorder the dimensions and test the memory usage. It will take much time to test once.

It will, but it's worth the effort in the long run.

wuruimao wrote:Actually i should reorder dimensions to make the small ones gone before large ones.

That's a rule of thumb but it's right more often than it's wrong. Element density will play a part as well and obviously this one will be as dense as it's possible to be. What the effect of that fact is on your optimal dimension order is anyone's guess.

wuruimao wrote:For the dimension with only one element, I think it's for the easy extention of our product.Actually it make sense.

You may want to clarify what you mean there; odds are that someone can suggest a better workaround unless you simply mean that you plan to use it for future elements as well. I'd never say never to anything, but having a single element dimension is something that I'd try to avoid at all costs. The reason you've already found for yourself in the difference between the two cubes.

Alan Kirk wrote: That's a rule of thumb but it's right more often than it's wrong. Element density will play a part as well and obviously this one will be as dense as it's possible to be. What the effect of that fact is on your optimal dimension order is anyone's guess.

I am rather confused about the re-order test result.
I remember in the re-order dimension interface, the percent change means the new order's memory usage compare to the old order's memory.
In the testing I got this result, 20228851.612903%..

It's rather special. It seems the re-order will save memory when the number is < 0. how ever I got this terrible result.