Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.6.0, 5.6.1, 5.6.2, 5.7.0, 5.7.1, 5.8.0, 5.9.0, 5.9.1
-
All
-
2672a9a767909eab04ec6706bdef8a891a8f3d21
Description
When populating a large TreeView there is gradually worsening performance issue as the treeview is getting larger. I attached the test app for reproducing the issue. (treeupdatetest.tar.gz)
In top of the window there is a text that helps in detecting the performance problem.
On a normal run (uniform row heights or no scroll to bottom), first 7 updates to the text look like this:
2000 ms (diff 0 ms), inserted 0%, tree rows: 594
2001 ms (diff 1 ms), inserted 0%, tree rows: 1194
2000 ms (diff -1 ms), inserted 0%, tree rows: 1794
2000 ms (diff 0 ms), inserted 0%, tree rows: 2394
2000 ms (diff 0 ms), inserted 0%, tree rows: 2994
2000 ms (diff 0 ms), inserted 0%, tree rows: 3594
2000 ms (diff 0 ms), inserted 0%, tree rows: 4194
On a failing run they look like this:
2000 ms (diff 0 ms), inserted 0%, tree rows: 594
2103 ms (diff 102 ms), inserted 0%, tree rows: 1194
3045 ms (diff 942 ms), inserted 0%, tree rows: 1794
4170 ms (diff 1125 ms), inserted 0%, tree rows: 2394
5321 ms (diff 1151 ms), inserted 0%, tree rows: 2994
6448 ms (diff 1127 ms), inserted 0%, tree rows: 3594
7682 ms (diff 1234 ms), inserted 0%, tree rows: 4194
Legend for the print:
- The first number is the time it took for 100 timer expires to be handled (20ms timer, this should always be 2000ms).
- Second number is the difference to previous time it took for 100 timer expiries (this should always be 0ms).
- Third number is the current progress of waiting for the 100th expiry to occur.
- Last number is the number of rows in the model.
The delay is not only longer when neither of the workarounds are used, but the delay also increases by about 1150ms on every time 100 additions have been done. Eventually the delay grows into several seconds and the UI becomes unusable.
The test app adds new items to end of the list and keeps the focus at the end of list. In short the code for updating is:
beginInsertRows(QModelIndex(), parents.size(), parents.size() + lines.count());
/* append children here */
endInsertRows();
treeView->scrollToBottom();
Please note:
- If we don't do the scrollToBottom(), the updates happen in constant time, regardless of the amount of items.
- If we set "treeView->setUniformRowHeights(true)", the updates happen in constant time, regardless of the amount of the items.
However for software with height items and focus on bottom of list (e.g. a news group reader with preview line(s), neither workaround can be used.
Since uniform row heights fixes the increasing delay problem, I assume that after the update the row height data is no longer cached for the already existing items (the ones that were not added), although the data should be in cache as the area of change is given and already existing list does not get changed.
Attachments
For Gerrit Dashboard: QTBUG-61763 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
242094,3 | QTreeView: small optimization in verticalOffset() | dev | qt/qtbase | Status: MERGED | +2 | 0 |
242095,3 | QWidget: set brushOrigin in paintBackground() only when really needed | dev | qt/qtbase | Status: MERGED | +2 | 0 |