InfoQube IM - Community

Submitted by Armando on 2010/05/11 23:06

A value of "1" in any of these 2 sections will tremendously slow down the item to item focus change.

Parents: 1

AND/OR

Siblings: 1

It gets worst with higher values.

30-50 siblings or parents will create about a 1-2 s disruption for the properties pane to refresh and "release the focus" to the next item... which makes navigation with an opened properties pane almost impossible.

30-50 seems like a big number, but it isn't actually. E.g. If one is working on a document with chapters and item-paragraphs, the number of siblings can easily reach 100 and much more, like 1000)

Interestingly, the children section doesn't seem to affect the item focus change too much.

The important thing is to be able to switch focus from item to item fluidly, with much disruption, if any.

Comments ? Anybody can confirm that ? Thanks.

[Edit : note that if you just leave your finger on the up/down arrow to have the items just fly by, you won't see any performance problem. I'm not talking about that. I'm talking about actually using the properties pane to display each and single items content as I'm moving up/down. When one does that, these issues are obvious -- well, here they are. I can provide a video if needed.]

Comments

I haven't got any other user's feedback for this one, but as it is easily reproducible here (in my DB) and since it might get lost in the flow of posts...

I created a mantis issue for it.

Mantis :

0982 When properties pane "fetches data" to populate certain sections (Parents & Siblings) properties refresh is slow -- Bug -- average

hmm

I've been meaning to check this out Armando, sorry for the delay

I tested this on a section of a grid where items sometimes have up to a couple hundred siblings and a large percentage of these have two parents

When I use the up or down arrow to move within the grid, I do not have this problem. It moves up roughly 20 items per second, down is same or quicker.

The properties pane actually only refreshes occasionally - it skips most items.

This is with filled fields, parents & siblings expanded in properties pane.

There is a display quirk - when it reaches the top or bottom visible item - where it seems to cycle through a few names (5 or so) before the visible grid actually scrolls down and catches-up

[quote=Tom]

hmm

I've been meaning to check this out Armando, sorry for the delay

I tested this on a section of a grid where items sometimes have up to a couple hundred siblings and a large percentage of these have two parents

When I use the up or down arrow to move within the grid, I do not have this problem. It moves up roughly 20 items per second, down is same or quicker.

The properties pane actually only refreshes occasionally - it skips most items.

This is with filled fields, parents & siblings expanded in properties pane.

There is a display quirk - when it reaches the top or bottom visible item - where it seems to cycle through a few names (5 or so) before the visible grid actually scrolls down and catches-up

[/quote]

Thanks for your feedback.

The problem is not when leaving the finger on the arrow button so that items fly by, but rather to move from item to item almost "slowly enough" so that the properties pane refreshes for each item. If you do that, you'll see that some data affects the speed tremendously -- parents and siblings mainly.

I rarely leave my finger on the arrow, but move from item to item at a normal speed and often have to look at the properties pane. But it's often too slow or chunky so I have to close the properties pane when I don't need it.

Is that clearer ?

I think it also has to with parents being collapsed or not in the properties pane. But not only. See : Will the number of parents an item have affect performance ? (comment-7265)

[quote=Armando]

I think it also has to with parents being collapsed or not in the properties pane. But not only. See : Will the number of parents an item have affect performance ? (comment-7265)

[/quote]

I'm not sure what you mean by "parents being collapsed" or for that matter why they wouldnt be shown in the properties pane?

But certainly my experience would argue against it being a problem with having many siblings

FWIW I use inheritance very little [edit] and have no column equations in this sample (and few in general) [/edit]

[quote=Tom]

[quote=Armando]

I think it also has to with parents being collapsed or not in the properties pane. But not only. See : Will the number of parents an item have affect performance ? (comment-7265)

[/quote]

I'm not sure what you mean by "parents being collapsed" or for that matter why they wouldnt be shown in the properties pane?

But certainly my experience would argue against it being a problem with having many siblings

FWIW I use inheritance very little [edit] and have no column equations in this sample (and few in general) [/edit]

[/quote]

I'm not sure I understand your question. There's a "parent" section in the properties pane, and if the hierarchy is deeper than 2 levels, you can expand the parents and show their own parents, add infinitum . This is what I mean parents being collapsed/not collapsed.

[quote=Armando]

[/quote]

yes, clear - sorry - for some reason I thought you were saying one could get a parent to not show at all in properties pane

Okay, apologies about the confusion:

I think my file is too simple/straight-forward to be causing these problems

FWIW:

it's not a problem here with the sample items having:

a parent expanded to three levels in the properties pane
a parent that shows only at top-level in only one grid

at that - there is a pause and there's a fair bit of jumpiness within the properties pane

No worries, Tom. I REALLY appreciate all feedback, and yours was generous and detailed. Thanks.

Just another note about this specific properties pane performance problem :

One of my items has 19 parents, and these were all expanded to the 5th level. IQ froze for about 2 min when I got to that item.

I have no idea how the parent-child relationship is implemented, but I am slowly getting the feeling it's maybe a table in the database.

This could explain the slowing when there are multiple levels or parents/children, since (depending on how it is implemented) it could require database queries and sorting to get each level.

Also, since everything is an item and the grids are just views, I guess all items are in one big table. Which would mean no matter how few items you are looking at you will be working on all items when finding parents and children.

If it incurs slowdowns as bad as the ones described in recent posts, then it might be worth looking at the design and seeing if there is some way to do it differently to better support hierarchical data?