Re: [Nautilus-list] hidden files bug



> > I was looking at fm-directory-view.c:real_display_pending_files().
> > As it seems, currently hidden files are present in the list of
> > files passed to directory views even if hidden files are turned
> > off in the preferences. This probably hurts performance a bit
> > when viewing directories with lots of hidden files (e.g. home
> > directories). I tried to dig into the code to find out where
> > the problem lies, but I thought I'd rather report it now.
> >
> > I couldn't quickly find out where the GList of pending files
> > (files_added) is constructed. I got somewhat lost in
> > nautilus-directory*.[ch], but I suspect a fix may be possible
> > somewhere in nautilus_directory_get_info_for_new_files in
> > nautilus-directory-async.c. I'm not yet able to fix this myself.
 
> Calling this a bug is silly.

Sorry.

> You think that it *might* be faster if you 
> filter out the hidden files at an earlier level. But it might not be 
> faster.

Seeing the complexity behind it all, I don't think it would be
good to optimize for an (possibly) uncommon case. Surely not without
hard evidence of a bottleneck.
 
> Older versions of Nautilus did filter out hidden files earlier, and this 
> led to a bug where if you renamed a file to a hidden name, it would stay 
> forever with the non-hidden name, because the name change would not be 
> reported to the directory view.

I had tried a check within fm-directory-view.c, which worked in that case.
But the benefits are probably unmeasurable. I think it only saved one
signal emission per hidden file.

On a sidenote, an interesting thread on gtk+ signal emission speed can
be found here:
http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00398.html
 
Christian Glodt






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]