Re: [PATCH] Add more nautilus_file..._nocopy variants

[Alexander Larsson <alexl redhat com>]

On Mon, 2005-12-05 at 18:29 -0600, Federico Mena Quintero wrote:
> On Fri, 2005-12-02 at 19:49 +0100, Christian Neumair wrote:
> > I hoped to significantly speed up Nautilus by caching each
> > NautilusFile's URI and exposing API for getting cached file info.
> 
> I'm putting the work on file chooser optimization on hold until Kris
> commits his async API changes for GtkFileSystem.
> 
> In the meantime, let's find out why Nautilus is slow :)

Yeah, this is the right approach, measure first, then fix. Of course,
having spent a few years doing this I know its not as simple as you'd
think. :)

> One big problem I found with the file chooser is that it is hard to know
> when it is *really* done loading a folder and done displaying it.  Does
> Nautilus have a place where it knows it is done loading?

The asynchronicity makes concepts like "finished" hard.
fm_directory_view_end_loading() might be a good point though. We
continue to do low-prio dynamic updates after it, like updating deep
counts for folders, but at this point the user can start seriously using
it. I'm not sure that includes all displaying though, some painting
might be done in idles. You need to test it out.

What are you trying to optimize? New window speed? Cold-cache case or
hot-cache case? Have-to-sniff case like /usr/bin or an easier case where
all files have extensions?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an underprivileged Amish cowboy on the edge. She's a transdimensional 
Bolivian research scientist with an incredible destiny. They fight crime!