Re: [Nautilus-list] directory content cache idea

[christian glodt ist lu]

On Mon, 11 Jun 2001, Darin Adler wrote:

> Believe it or not, we planned this exact feature, caching file names and 
> enough data to display the file's icon and text undernear it in metafiles,
> when we originally planned Nautilus. However, I'm not sure it will have 
> the effect you expect, though.
>  
> I think that you are expecting that it will cause the files to appear 
> faster in directories you have already visited. It's true that it will 
> allow us to show files before reading the directory.

I think that would help to accelerate navigation.
 
> But are you sure that the current slowness is due to the speed reading the 
> directory? Creating the data structure to show the files could easily be 
> the problem.

This could definately be the case. I didn't profile anything, I just
assumed there was a bottleneck because of the disk activity. But there is
also a lot of cpu activity. I'm not familiar with nautilus' guts, so
I can not say much about the data structures involved. I guess these
things can be solved by profiling and caching/optimizing.

> I agree that showing all the files at once would get rid of 
> the redrawing, but Yoann and I recently had to add code to prevent it from 
> showing all files at once because of how slow it was. Try changing the 
> FILES_TO_PROCESS_AT_ONCE constant in fm-directory-view.c if you want to 
> experiment with this.

Even if redrawing is not the bottleneck, the re-layouting of the icons in
the icon view is irritating. I think it can be reduced by caching icon
sizes and positions in the metafile. The drawing method would have to be
altered. Instead of adding items and resorting the view according to the
user setting, the icons could be created in their final position.
A placeholder icon could fill the gap while the file details are
determined, somewhat like the placeholder present before thumbnails are
loaded. And maybe there should be a preference to turn this on/off.

> Anyway, besides the fact that we'd need to do other speedups and fixes to 
> reap the rewards of storing this data in a metafile, we have one other 
> problem. Is it going to be acceptable UI to see files in a directory that 
> don't exist until the entire directory is loaded? A file that was once 
> there will show up, and it won't disappear until the load of the directory 
> is finished.

I understand the issue, but I don't think it is unsolveable. Afterall:

	chris Duke:/usr/bin > time ls -lA > /dev/null

	real	0m0.038s
	user	0m0.030s
	sys	0m0.000s

	(1105 entries in this directory)

Maybe it would be worthwhile, for the sake of speed, to circumvent
nautilus' OO model for this case. In the local case an optimized
function could use an ordinary readdir call (maybe even circumventing
gnome-vfs?) to quickly get the file list and filter out of the cache
non-existing entries.

I know this would be a Dirty Hack(tm). And I'm not proud of the idea.
 
> Also, remember that the user can configure what's displayed underneath a 
> file's icon. So it's not always the size, so we might need to cache more 
> than just the size to make this kind of feature work well.

IMHO these are of secondary importance. They could be updated once the
icons and filenames are in place, as it is done now.
 
> if you do experiment with this and find that it works well, I look forward 
> to seeing the patch!

I'm not a nautilus-hacker (yet (?)). I need to consult the developer docs
before I will even be able to understand the architecture.
I'll let you know if I happen to come up with something...

For the record, this is how I would imagine the loading of local directory
contents:

    quickly_get_list_of_files();
    read_cache_file();
    foreach(file_in_cache) {
        if (file_in_cache IN list_of_files) {
	    draw_placeholder_icon_with_correct_size_and_pos();
        }
    }
    asynchronously_update_placeholder_icons_to_real_icons();

Please tell me if this looks like I'm smoking crack.

Christian Glodt