Red Hat Bugzilla – Bug 178872
gnome file dialog takes 30-40s to open /usr/bin after booting
Last modified: 2007-11-30 17:11:22 EST
Description of problem:
When selecting an application to view a file in firefox, the gnome file dialog
takes 30-40s to display any contents of the directory listing of /usr/bin on
ext3 when the cache is cold. In contrast, an ls after a fresh reboot takes
1-2s. This is likely due to the fact that ls makes use of the file type
information returned in struct direntry64.d_type while the gnome file dialog box
performs a stat() on each individual file name. Ideally the dialog box would
display results as they are fetched, which is to say that the names should be
displayed as they become available, and only after all the names in the
directory are loaded from disk should the stat() to determine file modification
time / permissions / size begin.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. reboot (or umount a filesystem with lots of entries in a directory)
2. attempt to use the file dialog box on a directory with many entries
3. wait while lots of disk access occurs
The time spent waiting is very long.
The time spent waiting is very short.
UI improvements are good.
The reason is more likely to be that magic file sniffing is used to determine
the mimetype (for the icon, and for filtering) for files with no well known
extension (common in /usr/bin). Reassigning to gtk+.
This activly being worked on upstream (in the kris-async branch), with the
goal of loading directories asynchronously, and display results incrementally.
THis is not going to be fixed in time for FC5, though.