## Summary Since 70cddc4b11644eed3c049c52bf303481cb8104c2, 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 1. Browse to a folder with 3000+ subfolders, for example `/usr/share/doc` on my system 2. Press <kbd>Ctrl+F</kbd> to start a search 3. Type in a search string 4. 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 <details><summary>Sample timings</summary> Sample timings on my NVME laptop local storage for commit 70cddc4b11644eed3c049c52bf303481cb8104c2 (and the current HEAD on main too, 274f43f939462d5d1991627214a6275b501b57a5): * `/usr`, 12 folders: instant response to <kbd>Ctrl+F</kbd>, 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, 3659d451c54116fb41e6cb324f01e274fe785af8, the timings on my system are * `/usr`, 12 folders: instant response to <kbd>Ctrl+F</kbd>, 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 </details> <details><summary>Sample bisect</summary> ```git 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) ``` </details>