FileChooser extremely slow to display search results in its ListView widget in realtime
I've been testing the FileChooser's search performance with GTK 4.10.1 as provided by Fedora 38, and there are some highly visible performance problems remaining on my computers.
Context
@carlosg's nice !5611 (merged) seems to provide better / more complete results than before, and is meant to provide huge search backend performance improvements (i.e. instantaneous search results) due to the way it structures its queries.
However, in practice I am still seeing the very slow performance symptoms I had reported before as part of issue #4133 (closed). i.e., "I have to wait one second between each character I type while the whole thing freezes up" kind of slow (otherwise the IBus character jumbling bug comes mess with it even more).
Now that the search backend itself is fast, short of doing the performance hack I was suggesting with a longer SearchEntry search-delay
, maybe there is something that can be optimized in ListView
, which is the widget being used by the FileChooser if I am not mistaken.
Methodology
On a fresh boot, after letting Tracker (especially tracker-miner-fs) settle, I opened Epiphany 44.1 (package from Fedora 38, not the flatpak version) and opened the file chooser with Ctrl+O
, then selected the Home folder, activated the search field, and ran various search queries, trying to progressively type "journal de bord" at the speed I am allowed to do it without encountering the ibus bug.
Profiling output
For the sake of these measurements, I have turned SELinux off entirely, rebooted the machine, and tested both on Xorg (where the issue is most visible) and Wayland.
- GTK 4.10.1 filechooser search slow on workstation Xorg sysprof syscap.tar.xz
- GTK 4.10.1 filechooser search slow on workstation Wayland sysprof syscap.tar.xz
The Wayland version is much faster (and apparently less likely to trigger the IBus / mainloop blocking bug), but some sluggishness can still be felt, it's not 100% smooth. That said, using a patched version of Mutter with the infamous dynamic triple-buffering code under Wayland, the issue becomes even harder to observe (that doesn't mean the performance issue doesn't exist though ;)
Here are some screenshots of the above recordings.
Under Xorg:
Under Wayland (not using triple-buffering):
Additional information
Hardware:
- AMD Radeon "Pitcairn" R7/R9 270 graphics card, running on the open source drivers that come with Fedora by default
- Intel® Xeon® W3520 × 8 CPU
- 24 GB of RAM
- The majority of my files are on a conventional (non-SSD) 2TB hard drive, though performance-critical ones (such as dev folders, flatpak caches, thumbnails and tracker directories, etc.) are symlinked to a location on a separate SSD.
With that said, the HDD does not seem to be the problem here: if you look at the Wayland sysprof output (I forgot to record disk IO in sysprof for the Xorg test), we can see there is pretty much no disk IO going on, so it seems to be purely a graphics stack performance optimization in GTK.
On this machine, Nautilus 44.0 is able to return results much faster than Gtk FileChooser, although it uses the same widgets (ListView) and a slower search backend (its tracker backend is not yet revamped in the main branch, and it also has its own fallback "simple search", so it should be slower), and the only difference I know is that it doesn't spam the graphics stack / listview, due to the same performance trick I had proposed in #4133 (closed), so this indicates to me that the issue in FileChooser's search results performance is probably related to the view rather than the backend.