Recursive search much slower after image preview sidepane addition
Summary
Since 70cddc4b, searches take a very long time to start up when the root folder for the search is particularly big. It's always been... not great... but it gets approximately 2-3 times worse with this particular commit.
Note that this is a freeze, a UI lock-up. This can be demonstrated by trying to resize the window during the longer pauses: it doesn't redraw until whatever it was doing in the Gtk UI thread finishes.
Steps to reproduce
- Browse to a folder with 3000+ subfolders, for example
/usr/share/doc
on my system - Press Ctrl+F to start a search
- Type in a search string
- Wait (this bit varies)
Symptoms
- No response for several seconds before the search box and entry cursor is shown
- Very laggy typing
Expectations
- Instant response to starting a search. The pathbar should change instantly, and show a cursor for text entry.
- No typing lag
Observations
All slowdowns I've seen seem to be unaffected by priming the in-memory file system cache with the tree's content. The cache can be primed by going to /usr
first and searching for something before testing with wider subfolders deeper in.
I'm using tumblerd 4.17.2 from Debian experimental, and I purge my thumbnail cache and restart tumblerd before each test cycle to keep things consistent. I don't think this one is caused by tumblerd, however!
The typing lag seems to be dependent on the number of search results currently visible, and even the "unaffected" commit I tested below has a bit of this. The affected commits are however much laggier.
Output
Sample timings
Sample timings on my NVME laptop local storage for commit 70cddc4b (and the current HEAD on main too, 274f43f9):
-
/usr
, 12 folders: instant response to Ctrl+F, no lag in typing -
/usr/share
, 461 folders: 2 seconds response, appreciable (~1s) lag in typing -
/usr/share/doc
, 3849 folders: ~8 seconds response, multiple seconds typing lag
For the "unaffected" preceding commit, 3659d451, the timings on my system are
-
/usr
, 12 folders: instant response to Ctrl+F, low typing lag -
/usr/share
, 461 folders: ~1 second response, typing lag feels worse? -
/usr/share/doc
, 3849 folders: ~3 seconds response, slight typing lag
Sample bisect
git bisect start
# bad: [274f43f939462d5d1991627214a6275b501b57a5] I18n: Update translation is (75%).
git bisect bad 274f43f939462d5d1991627214a6275b501b57a5
# good: [4a36de471beb142047d3fa80391babef8db8cc04] Add posibillity to set custom color to specific files (Issue: #160)
git bisect good 4a36de471beb142047d3fa80391babef8db8cc04
# good: [141d0d420098f0ad304d017118f09b15a15cd2e7] I18n: Update translation vi (73%).
git bisect good 141d0d420098f0ad304d017118f09b15a15cd2e7
# good: [14caba741abe194c1762b6da02ad04b2fe92f577] I18n: Update translation da (93%).
git bisect good 14caba741abe194c1762b6da02ad04b2fe92f577
# good: [86427849615744660cb4edc211ff3f8e614ad101] I18n: Update translation vi (72%).
git bisect good 86427849615744660cb4edc211ff3f8e614ad101
# good: [d35133e5a36e2574f0a691f94d6d8f88aeb2ef23] I18n: Update translation sv (99%).
git bisect good d35133e5a36e2574f0a691f94d6d8f88aeb2ef23
# bad: [1f0f54bcfae89e9d783f828a2dcfa68289483655] Introduce separate class for 'thunar-job-operation-history'
git bisect bad 1f0f54bcfae89e9d783f828a2dcfa68289483655
# bad: [c40006de5c13ce14d40e0aaae6e85d65e926fb03] Shorten wait time to show file transfer rate (Issue #888)
git bisect bad c40006de5c13ce14d40e0aaae6e85d65e926fb03
# good: [87e3c780593b9699ded7052c3ad4a58e740fac08] Limit size of undo/redo history (issue #819)
git bisect good 87e3c780593b9699ded7052c3ad4a58e740fac08
# bad: [70cddc4b11644eed3c049c52bf303481cb8104c2] Image preview sidepane (Issue #357)
git bisect bad 70cddc4b11644eed3c049c52bf303481cb8104c2
# good: [3659d451c54116fb41e6cb324f01e274fe785af8] Prevent GLib-GIO-CRITICAL messages if 'file_>info' is not set
git bisect good 3659d451c54116fb41e6cb324f01e274fe785af8
# first bad commit: [70cddc4b11644eed3c049c52bf303481cb8104c2] Image preview sidepane (Issue #357)