Bug 151206 - Auto filtering search entry / text input widget should use a timer-based search activation algorithm to improve performance
Summary: Auto filtering search entry / text input widget should use a timer-based sear...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Andreas Heinisch
URL:
Whiteboard: target:7.6.0
Keywords: needsDevEval, perf
Depends on:
Blocks: AutoFilter Performance
  Show dependency treegraph
 
Reported: 2022-09-27 21:12 UTC by Jeff Fortin Tam
Modified: 2023-04-04 16:14 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Fortin Tam 2022-09-27 21:12:03 UTC
When you open this heavy sample spreadsheet for example: 
https://fortintam.com/public/libreoffice-augustin-benchmark--million-rows-spreadsheet.ods

...if you create an autofilter on column D, and then click the arrow to open the autofilter GUI, and then try to type "example", you will have to wait a long time for the UI to unfreeze. This is what I observed with LibreOffice 7.4.x under Linux (Flatpak version from Flathub) on X11.

In extremely large or diverse spreadsheets, the autofilter dropdown GUI widget is very laggy, probably because it tries to do "too much work, at the wrong time".

This seems to be the same issue as bug #122419 which was reportedly fixed in 7.1, but I'm still seeing it in 7.4, hence the new report. Perhaps my large spreadsheet exhibits the problem more vividly.

If LibreOffice tries to filter this GUI's checkboxes elements immediately everytime you type a character (which is my guess, because the UI *instantly* locks up as soon as I start typing the first character, without waiting for me to finish typing), then that would be the reason, guaranteed. In that case, the trick is to use a generous timeout (ex: 500ms) "after the user stopped typing". I can swear than 500ms is not too long of a timeout, according to my calculations and to many many instances of software where I've had this implemented and saw successful results.

The logic and philosophy can be seen here:

* https://github.com/getting-things-gnome/gtg/issues/281 (fixed, and proven to have made a huge difference)
* https://github.com/Drive4ik/simple-tab-groups/issues/794 (fixed, and proven to have made a huge difference)
* https://gitlab.gnome.org/GNOME/nautilus/-/issues/1731 (a good general argument and theoretical overview of why this is relevant)
* https://gitlab.gnome.org/GNOME/gtk/-/issues/4133#note_1486168 (empirical proof provided)
* https://gitlab.gnome.org/GNOME/gedit/-/issues/398
Comment 1 Roman Kuznetsov 2022-10-19 19:14:08 UTC
I confirm the problem with Autofilter in

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4d9b83a417bbde8148b67d2ab0abe9f4ae285276
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: threaded

And we need some dev's opinion here

Caolan, Noel what do you think about this suggestion?
Comment 2 Noel Grandin 2022-10-20 06:29:25 UTC
That's a reasonable idea, and I'm sure we do that elsewhere already
Comment 3 Commit Notification 2023-04-04 16:14:06 UTC
Andreas Heinisch committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/37928bef1c23f30df04bc7e95fcbc202c8cb4299

tdf#151206 - Sc Auto Filter: filter items after search edit timeout

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.