501705 - unifinder: the display of thousands of events creates a huge delay before Thunderbird becomes available

Status: NEW

(Calendar :: Calendar Frontend, defect)

Description

[Wolfgang Sourdeau]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.0.11) Gecko/2009061317 Iceweasel/3.0.11 (Debian-3.0.11-1)
Build Identifier: 20090608035852

See title.

Ideas:
- should we put a configurable limit on the time range being displayed when no limit is specified?
- is there a mechanism that improves the rendering of thousands or rows in table/tree/list elements?

Reproducible: Always

Comment 1

[Philipp Kewisch [:Fallen][☁️📆]]

The <tree> element can theoretically handle showing many events, but the problem is that we have no mechanism to retrieve only a subset of the shown events by count (i.e LIMIT 400, 30), ready sorted the way it should be in the unifinder.

We tried to improve this in the past by defaulting all installations to show events in the next X days, instead of "All Events".

I'm open to any improvements though. This could possibly get better when we have gloda, we should then be able to quickly show all events, even if there are very many of them.

Comment 2

[Wolfgang Sourdeau]

In 0.9 Inverse, we disabled the "show all events" option until a proper fix is found. Another related problem is that textual searches are done in javascript after the resultset was obtained, which is really not efficient. The filters should be handled in SQL for storage-based calendars and maybe in JS for memory calendars, but currently this always happen in memory.

Comment 3

[Philipp Kewisch [:Fallen][☁️📆]]

We've at least changed the default to "Next 7 days", so unless the user manually selects "All Events" it won't be *that* bad. I agree the search is really unefficient. The ideal solution would be to index items using gloda and then just select from there. This would be very fast.

Comment 4

[cm-schl]

We face exactly the same problem with a calendar containing thousands of events. Specially after clearing the search field in unifinder the whole program begins to block itself (and after some time you get asked if you would like to stop the script).
The change of the default to "Next 7 days" improves the performance until a user searched for the first time using "all events" - after that search, this options becomes the default chosen entry.

Wouldn't it be a bit better if Lightning would search only for non-empty strings?

In calendar-unifinder.js I tried to modify refreshEventTree() to search only if at least two characters have got entered:

function refreshEventTree() {
    let field = document.getElementById("unifinder-search-field");
    if (field) { 
      if (field.value != "" && field.value.length >= 2)
      {
        //from the original refreshEventTree function: 
        unifinderTreeView.mFilter.filterText = field.value;
        
        addItemsFromCalendar(getCompositeCalendar(),
                     addItemsFromCompositeCalendarInternal);
      }
      else
      {
        //clear all items in search result
        unifinderTreeView.clearItems();
      }  
    } 
}


At the moment I have no problems clearing the search field in unifinder - Lightning doesn't begins to search and sort all events of that big calendar. Unfortunately at the moment the tree at program start (with open unifinder) still gets filled automatically with all events and sometimes when you start a search and after some moment try to clear the field, some search results get inserted in the previously cleared unifinderTreeView.

Comment 5

[Emily Bowman]

FWIW the biggest problem doesn't seem to occur anymore; blank searches with tens of thousands of results are almost as instant for me as a search with a single result. From a UX viewpoint it's still weird that no search means list every single thing, but at least it doesn't break Thunderbird now.