Please describe the problem:
When opening a large directory in GtkFileChooser (e.g. /usr/bin), the file chooser can become unresponsive while it thrashes the disk for a long time.  Listing the same directory from a terminal takes an order of magnitude less time.

Is it possible to quickly populate the file chooser list with filenames first, and then go back and asynchronously fill in details like modification time later, if that's where the extra disk activity is coming from?  Is there a reason this takes so much longer than listing the directory from the console (e.g. does gnome-vfs2 require one round-trip per file in the directory, and is this fixed in gvfs)?

This is particularly a problem in firefox, because its "Open With" system is broken, and you often need to go find the correct binary to open a certain filetype with.  Just typing in a path that includes /usr/bin causes the file chooser to jump to that directory and then the file chooser locks up for 10 seconds.



Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information: