TM1 Forum

Does anyone have any idea why using Edit Element Attributes after right clicking on my product dimension (16,000 items?) takes between 5 and 10 minutes to load at 100% CPU whilst viewing the same information in the }ElementAttributesProduct cube is almost instantaneous?

I keep being told by IBCoglix about the multi-million member dimensions at Pelephone - it must take about a year for them to load at that rate!!!

I am having a hard time explaining to a client why it takes so long as I simply don't understand it myself!

Yes, try turning off the properties window in the view menu of the subset editor. Same goes for just selecting elements, we have an employees dimension with 22,000+ entries and lots of attributes for each. With the properties window turned on, when you select the top level "All Employees" it has to go away and populate that window for all the child elements, hence taking ages.

Why it should be so much slower i don't know, but it does make a massive difference so i always try to ensure people only have it turned on if they really need to.

I think John's talking about right clicking on the dimension name then selecting "Edit Element Attributes" which then says for big dimensions "This is going to take ages, are you sure?"

Probably both this front end and the subset editor's properties window have the same issue, but I don't know what it is. Though it seems to be a display issue as it's the client that does all the work, not the server.

Hi Steve

Martin's right - and the properties window makes no difference - it was already closed. And boy s that client working - 100% CPU for 10 minutes to load something that the control cube returns in seconds!

Unusually for a TM1 interface message the one Martin refers to is accurate and to the point - unfortunately

Is this expected (if unacceptable) behaviour then?

J

Isn't it because cube viewer only preloads a few cells from cube }ElementAttributes_ and loads more only as you scroll down, whereas the Attributes Editor loads the whole shebang when it opens?
A network traffic analysis between client and server box with wireshark might demonstrate it. Or try to slice the whole }ElementAttributes_ cube in Excel and see how long it takes compared to the Attributes Editor.

Isn't it because cube viewer only preloads a few cells from cube }ElementAttributes_ and loads more only as you scroll down, whereas the Attributes Editor loads the whole shebang when it opens?

Sounds plausible. but that doesn't explain why a filter by attribute on the entire dimension takes seconds and also presumably has to read all elements and their attribute values? OK it's probably a little more efficient that having to read all attrinutes and thier values in one go as it only has to read the list of attributes and then one of their value sets at a time, but the order of magnitude of difference is far too HHHUUUGGE for that to be an explanation.

J

This issue has been around for ever, it may sound obvious but the best advice is to NEVER use the attribute editor for dimensions with more than a few thousand elements. Any really large dimension should be maintained by TI, including adding and removing attributes. If there is a need for any manual adjustment of attribute values this can be easily accommodated either in the cube viewer or in a spreadsheet (that could be made as fancy or plain vanilla interface wise as you like) that will render in seconds what takes the attribute editor 15 minutes.

I think the issue is that the whole grid is being built client side. This problem applies to all the TM1 "grid" dialogs (try opening the client/groups dialog when you have 2000 clients x 500 groups, same problem!)

Thanks Scott - At least I know it's not something I have done this end.

Sounds like sloppy design then.

Sorry John, realised what you mean about 3s after hitting "submit"...

Yeah, its been like that forever and any dim i have thats too big for it will get manipulated via TI. I'll add new attributes that way, or if ad-hoc editing is needed then i'll use the cube viewer instead. It is very bad programming tho, should have been sorted years ago...