Working with large directories

[Tim]

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 at 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.