InfoQube IM - Community

Submitted by jsolka on 2010/02/11 12:34

I'm not sure whether this wasn't mentioned before, so I just put in suggestions:

1. While hoisting: to hoist an item or to hoist searched items is really fast, but to "unhoist" them takes really long, and also the way the grid is displayed changes (in terms of levels shown, at least).

2. Same thing is happening while filtering. As I filter for colors it takes a long time to "unfilter". And also, sometime the things are not the same. Another thing. When I moved and item and changed its level, then I couldn't fix its position in "filtered" mode. It would be always the last, for instance. When I have a lot of items I may miss something when it doesn't appear when I think I put it last. Those are just the things that I'd like at some point to be improved.

Much obliged,

Jay

Comments

I added this to my "reference list" of performance problems. (Armando's list.)

Jay : you double "posted" or double "threaded". ;)

I think the previous thread could be deleted (This is a job for the admin.)

Thanks for adding to your list.

In ref to deletion -- sure -- I don't really know how it happened.

Take care,

Jay

Are un-Hoisting and un-filtering slower than simply opening the grid. That is:

Measure time to remove the filter
Close grid
Measure time to re-open grid

i.e. perhaps returning to the un-hoisted / un-filtered display is long because there are lots to items... (which is another issue altogether... known and to be addressed soon)

hoist to a grid displaying 733 items (with some hierarchies) : 42.5s

UnHoist to a grid displaying 9 items (collapsed hierarchies) : 6.5 s

hoist to a grid displaying 10 items (single items, no trees) : 5 s

UnHoist to a grid displaying 740 items (lots of hierarchies) : 66.5 s

Opening a grid displaying 740 items (same one as the unhoisted one above ) : 67 s

Save item state is on.

Hierarchy is off

Sort Filter :

focus,date, xmo, noe, order, ordre, Urgency desc, ABCD_priority, priority desc, DoAc, links desc, itemcreated

Filter :

nbparents = 0 | check is null and lu is null

[quote=Pierre_Admin]

i.e. perhaps returning to the un-hoisted / un-filtered display is long because there are lots to items... (which is another issue altogether... known and to be addressed soon)

[/quote]

I think that is the main problem here. Filters could also be partly responsible.

Sort filter change :

When I remove the sort filter completely I get :

hoist to a grid displaying 10 items (single items, no trees) : 5 s

UnHoist to a grid displaying 740 items (lots of hierarchies) : 22 s

Changing the sort filter to itemcreated, and

updating the 740 items grid : 25 s

UnHoist to a grid displaying 740 items (lots of hierarchies) : 23 s

So filters have something to say too in terms of performance.

What's the max length for a filter before destroying performance ?

Humm... you mean "sort" or "filter"

Applying a filter depends on:

the number of fields in the filter
the field types (yes/no are faster)
the size of the database (most likely, the impact is larger for text fields)

Applying a sort depends on:

the number of fields to sort <<-- multi-level sorting is always a performance factor, for all apps
if some sort fields are not in the grid or in the filter, these add up to the list of fields to retrieve
the field types (yes/no are faster)
the size of the database (most likely, the impact is larger for text fields)

[quote=Pierre_Admin]

Humm... you mean "sort" or "filter"

Applying a filter depends on:

the number of fields in the filter
the field types (yes/no are faster)
the size of the database (most likely, the impact is larger for text fields)

Applying a sort depends on:

the number of fields to sort <<-- multi-level sorting is always a performance factor, for all apps
if some sort fields are not in the grid or in the filter, these add up to the list of fields to retrieve
the field types (yes/no are faster)
the size of the database (most likely, the impact is larger for text fields)

[/quote]

I meant "sort" -- I wanted to say Sort Criteria... but said "sort filter"... sorry.

We talked about that a while ago, so that's no surprise : the sort criteria's impact on performance seems to be (is?) a factor of the number of item displayed in the grid.

In any case, that means that the number of item ( from a few 5-10 to 750) in my past eaxmple has a 20 s impact on performance.

The previous testing was more to compare performance hoisting to "big grids" vs "small grids", and vs refreshing. But I took the opportunity to also measure the impact of long "sort criteria", etc.

SQL sorting algorithm are typically N x Log N or N x N (where N is the number of fields), so it is easy to see how multi-field sorting can become CPU intensive...

http://www.devx.com/vb2themax/Article/19900

(I remember we had this discussion before, IIRC, at the time you had something like 10 parameters in your sort criteria

)

[quote=Pierre_Admin]

SQL sorting algorithm are typically N x Log N or N x N (where N is the number of fields), so it is easy to see how multi-field sorting can become CPU intensive...

http://www.devx.com/vb2themax/Article/19900

(I remember we had this discussion before, IIRC, at the time you had something like 10 parameters in your sort criteria

)

[/quote]

Thanks for the clarification. So I guess that would explain why past a certain amount of criteria (not sure how many) performance suddenly drops.

Yes, N² can do that to you...