Until 2012 or so, if you started typing in a nautilus window, it would select the first file with those characters, and you could use mouse wheel to reach others. Some people add it back with patches.
I haven’t done that. My workaround is to use Ctrl-S to select with wildcards, though this doesn’t work great when multiple items match as I still have to scroll to find the right item. But this discussion is about problems with Find, which is now initiated by typing.
I see three minor issues with Find and one major issue. The minor issues in Nautilus 3.26.4, from the last LTS Ubuntu distribution, are that Find automatically switches to icon view; Find is a history location which means if you accidentally press a key it erases your forward browsing history; and a selected item is unselected when leaving Find. The major issue is that it is slow, seeming much slower than it should be for what it needs to do. I disabled Full Text Search: Set as default in preferences in case that was causing it to be slow.
Icon view: I’ve been using list view because of thumbnails. Nautilus doesn’t display thumbnails for very small icons as used in list view (unless you increase zoom level), and I believe that means it also doesn’t load them from disk. It also doesn’t try to create thumbnails, which is useful when listing images in a folder you’re going to move, which makes old thumbnails obsolete (saving both disk space and the time/CPU needed to create a thumbnail).
History: if you type more than one letter, there are two history locations. So you have to navigate back twice to return to the folder. Losing your forward history is a minor concern, but could be one reason people want a type-ahead select option.
Speed: I’m using a laptop from 2009 and have processors set to powersave mode (1/3 frequency) because it’s a warm spring day where I am and even with this setting, my laptop’s old fan is quite loud and the temperature sensors output 46° and 56°C. I also have a HD, not SSD. When I search for ‘a’ in a folder with 36 items in base directory and subfolders, it takes 5 seconds to return results from the current folder (or just initial results?) and another 6 seconds to return results from subfolders (total 32 results). Can’t scroll or select an item until after that 11 seconds.
If I press Back, then Forward again, it takes the same amount of time.
I don’t know if Find is searching within items, as the time it takes is dependent on the results. If I press Z, which gives just one result, it only takes 2 seconds (1 to display the result, another to finish searching).
If I search in a larger folder, it takes longer. Due to some bug, I don’t know how many files it has; after selecting all items and folders and checking properties, the ‘Contents’ keeps fluctuating, in size and total number of items, but one of the numbers it lists is above 3000. It took 34 seconds to return the (first?) results; after 98 seconds, searching finished and I could scroll and select an item. If I select all items, it lists ~1520 items. (For some reason, the “other items selected” count is fluctuating . . . it’s now down to 1489 . . . 1477 . . . and it takes several seconds to become responsive after switching to or away from it with all of those items selected, as seen by whether the info bar has an opaque background. CPU at maximum: apparently thumbnails are being created, but I don’t know if Nautilus might still be unresponsive with that many items selected even if thumbnails weren’t being created.)
In 0.15 seconds, time find ./ |wc -l shows there are 4654 items in the folder and subfolders.
Maybe Nautilus examines files to see their file type and so on; maybe it looks at media data before a user asks to examine a file’s properties. But why is it so slow when the same search is repeated on a small number of files?
For some unknown reason, as I type this with Nautilus open to the smaller folder with ~40 items, top -p <nautilus's PID> reports Nautuilus to be using 5% of a CPU core. (Several minutes later, this has stopped.) The 11-second search for ‘a’ in this small folder increases nautilus’s time by over 9 seconds compared to the start of the search, showing that this is not a disk access issue. There is significant disk access the first time the search is run (LED light and an old hard drive that makes noise on read/write makes this obvious), but it isn’t why Find is so slow.
Is there something special about my system that makes Find so much slower, and worse, than the old type-ahead select for opening a file in the current folder? Why does Find take so much CPU time, and can it be improved?
Edit: I have discovered the ‘Full Text’ button in search options, but it takes the same time as the File Name button; 11 seconds for ‘a’, 2 seconds for ‘z’. It also doesn’t return text files (extension .fx, encoding CP932) that have ‘z’ in their contents. Is it different for the latest Nautilus version?
