Tim: >> Nautilus seems to sniff the files to discover their types, and a >> plug-in tries to generate a thumbnail image for the file. Both these >> features are painfully slow with moderately largish directories. >> >> >> I've used the emelFM2 file manager as an alternative, it doesn't show >> thumbnails of files. And it does let you do some wildcarding to >> show/hide files in the lister gadget. (And it's much faster...) fred smith: > I think it's most likely not that nautilus, etc., are slow in > large directories, it is that large directories take a long time > to search for files, making any action on those directories much > slower than normal. I didn't say searching, just listing. But the *noticeable* problem with Nautilus, that's not noticeable with other file managers, seems to resolve around sniffing file contents to work out file types. Get Nautilus to show a directory with say a smallish number of large video files (it only takes around 200 files), and it takes an age to do so. Get it to show a similarly populated directory of (much smaller) plain text files, and it's much quicker. Even more quicker if you turn off generating preview images for text files. The generating of the thumbnails is timeconsuming, also the rendering of showing them in the lister. You can see the slowness of the latter, by itself, by going back and browsing a directory that has had thumbnails already generated and cached, previously. Even generating thumbnails for JPEGs is timeconsuming. But, at least, you could set a filesize threshold so that it'd ignore the huge image files, even if you couldn't easily set it to not show any preview images for certain file types (old Nautilus gave you options for text, sound, and /other/ file types). i.e. I'd, long ago, done enough comparative testing to confidently point the finger at the reason that I did. It's not just Nautilus. You could try double-clicking on a JPEG file to open it with a simple program like eog (eye of gnome), which would take an age chugging through all the files in the directory, to work out which it could work with, before even showing you the file that you wanted to look at (if designed better, it'd show me my chosen file, first, then start directory browsing, afterwards). In a large directory, the wait could easily outlast my patience. Yet, you can simply "ls -l" the same directory, or browse it with emelfm2 or midnight commander, or any other simple file browser, and you get the results in a snap. File sniffing is timeconsuming, and CPU-consuming. You've got to identify the file type, which means burrowing in to some degree, on each and every file, and comparing them against your list of file types (which seems to work in a slow manner). Then, for more delays, generate a thumbnail of said file. It's, also, timeconsuming for it to check through its cache, to see if it's already got a generated preview image, when you try to browse a directory. So, periodically, I'd delete the cached images to speed things up (and to reclaim oodles of wasted drive space). e.g. rm -f .thumbnails/fail/gnome-thumbnail-factory/* .thumbnails/large/* .thumbnails/normal/* Nautilus, pretty much, sucks as a file manager. About it's only use, for me, is to give me an (albeit slow) previewing of files in a directory. If I actually want to *manage* files and directories, something else is better. -- [tim@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
