TM1 Forum

How is it possible to find size of dimension in memory?
It seems there isn't information about it in }Stats... Cubes

In architect or perspectives have the properties window turned on and then click on the "Dimensions" group of objects then a "Memory Used" column will appear on the right hand side in the properties window for each dimension.
I've never really used it though as the memory a dimension uses is normally negligible compared to the rest of the model and I would also have doubts about how "true" those numbers are. It is useful for seeing the numbers of elements & subsets though.

Thank you.
I use it very rarely so I completely forgot about how to do it.

I made a big dimension - with more than 100 000 elements and decided to check it size.

As Declan pointed out, the amount of memory a dimension uses is meaningless. The only thing that matters is when you combine that dimension with others to build a cube, load data to it, and start creating rules. The number of populated (or fed) cells in a cube is the statistic you need to be paying attention to.

tomok,

I can't agree with you completely.
i.e. the dimension which contains hundreds of thousands elements (in my case) takes 70 Mb in Memory.
The Cube (with some rules and feeders) which contains the dimension takes 140 Mb in Memory

So they are at least comparable.

And of course in main cases memory which is taken by data or feeders is much more than which is taken by dimensions (but sometimes they are comparable)

I've had dimensions of around 3 million elements, which were definitely significant in terms of memory - around 500 mb and was around the same size as the cube. This was quite an unusual situation though. On a related point, there is no way to load a dimension 'on demand', despite there being a property in }DimensionProperties called 'DemandLoad'.

tomok wrote:As Declan pointed out, the amount of memory a dimension uses is meaningless. The only thing that matters is when you combine that dimension with others to build a cube, load data to it, and start creating rules. The number of populated (or fed) cells in a cube is the statistic you need to be paying attention to.

Actually, memory of a dimension is not meaningless. The larger your dimension is, the more demand it puts on the client side when certain operations are performed on it, such as filtering, paging, etc. It gets especially resource intensive on the client if there are lots of attributes.

When we encounter a dimension north of about a million members, we start to look closely at attributes and often times create cubes for non essential ones. This also eases the burden with end-users because browsing attributes (other than going into the brace cubes) is difficult in the attribute editor. In addition, the number of elements below a level is also scrutinized. It is much faster to break millions of members into more levels of a hierarchy than it is to dump them under all one single 'Total'.

blackhawk wrote:Actually, memory of a dimension is not meaningless. The larger your dimension is, the more demand it puts on the client side when certain operations are performed on it, such as filtering, paging, etc. It gets especially resource intensive on the client if there are lots of attributes.

You completely missed my point that having a large dimension in and of itself is largely irrelevant. It's all about when you start using that dimension in a cube. All those things you've mentioned would only be done in the context of a cube. Also, adding an attribute to a cube actually creates a cube. I stand by my original assessment.

tomok,

Well, actually, we have many applications that we create which use a dimension all by itself, without a cube attached. These are primarily used for indexing, looping, lookups etc. They are not irrelevant.

Yes, under the covers adding an attribute creates a cube, but that is not how the user is to interface with the dimension. When the user pulls up a dimension it is (partially, and in some cases, completely) downloaded to a client. This has an impact on network performance.

Large dimensions also take up server RAM and processing. When you execute a process that updates a dimension, it creates a working
copy in memory, if a user edits a dimension, or edits attributes, again, it creates a copy. So they are not completely irrelevant, but they are dependent on your usage.

BTW: According to the TM1 server chief architect, setting attribute values using the } cubes are strongly discouraged because it circumvents some internal checking and optimization routines.

Again, my original post was to point out to the OP that instead of worrying about how much memory his dimensions are taking up, he should pay attention to how much memory his cubes are taking up, as that is going to be the lion's share of RAM usage. If you go back and look at most of your TM1 implementations I think you'll find that less than 10% of the memory usage of TM1 is going to be for dimensions and 90% is going to be cubes (and yes, adding attributes to a dimension means cube usage). Of course, these are round numbers. I'm sure you can tell me about a model you did for someone that had no cubes at all.

Tomok,

I would agree with that. If dimensions are more than 20% of your system, I would question the architecture. Very rare cases are those which are dimension heavy.

HA! Speaking of that...I can recall (way back in Applix days) we had one customer that was using TM1 kind of as an ETL tool translating data from one system to another. Mainly because they could edit the hierarchies without using a database. It is a pain to re-org a hierarchy in a database if you don't have a good schema and a good front-end to make it work. I don't think they are still doing that, but there are some strange use cases out there to be sure....

That is what I love about TM1. Fast, furious and flexible.