RangedEventList Performance Issue

[Jon Wells]

Sandy,

We have an EventList wrapped in a FilteredList wrapped in a SortedList
wrapped in PaginatedList and when we apply a filter that filters out a
large number of the underlying objects, the table takes a while to
rerender.

Any ideas? We think it might have something to do with some of the
change handling code in PaginatedEventList where the
PaginatedEventList punts and fires a change event for it's whole
range. Also, seems like the ObjectListTable could be optimized a
little in the way that it handles change events. You have some
optimization comments in both these places. Wondering what you think
we can do here to speed things up.

-Jon

[Sandy McArthur]

On Feb 8, 3:17 pm, "Jon Wells" <jon.we...@gmail.com> wrote:
> We have an EventList wrapped in a FilteredList wrapped in a SortedList
> wrapped in PaginatedList and when we apply a filter that filters out a
> large number of the underlying objects, the table takes a while to
> rerender.

SortedList is poorly optimized for when elements change, it's
currently much better at adds and removes. The logic was getting to
hairy so I punted the problem and on a change event it just resorts
the whole thing. Easy but sloooow. If you move the SortedList down a
level it's contents will be more stable and should do fewer full
resorts. I think that will help a lot because FilteredList could
create a lot of volatility forcing SortedList to do a lot of work.

> Any ideas? We think it might have something to do with some of the
> change handling code in PaginatedEventList where the
> PaginatedEventList punts and fires a change event for it's whole
> range. Also, seems like the ObjectListTable could be optimized a
> little in the way that it handles change events. You have some
> optimization comments in both these places. Wondering what you think
> we can do here to speed things up.

In the sequence of:
1. Make it work.
2. Make it right.
3. Make it fast.

The EventLists are somewhere between steps 1 and 2, hopefully much
closer to 2.

I'll gladly accept patches to improve performance or squash bugs. If
you don't want to go there but can provide a test project that
demonstrates some behavior you think is too slow I'll try to provide
feedback and/or run it though a profiler and see what I find. Just zip
it up and attach it to an issue.

Let me know if EventList > SortedList > FilteredList > RangedList
works better for you.

[Jon Wells]

Sandy,

My coworker is trying to distill our problem into simple test that we
can get you. We may try to give you a patch later should we sort it
out. As a temporary workaround, we are calling
pagingList.setMaxSize(0) before calling filter on the deeper
filteredList, then restore the page size afterwards. This keeps our
table which is showing the paginglist from doing lots of rendering.

I think the problem we're encountering is actually in the
PaginatedEventList when we call filter on the deeper list. During
filter, events are fired up to the paging list as elements from the
list are "removed" by the filter. If the removed element is in the
current page and there are at least more than 1 page worth of
elements, the pagelist calls changed for the whole list. This causes
unnecessary rendering in the table.

Jon

[Jon Wells]

btw, i created an issue with an attached module which demonstrates one
of our probs.