After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 307915 - Gtk File Selection Widget is incredibly slow to come up
Gtk File Selection Widget is incredibly slow to come up
Status: RESOLVED DUPLICATE of bug 166601
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.6.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-06-16 13:57 UTC by sean dague
Modified: 2005-06-16 14:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8



Description sean dague 2005-06-16 13:57:09 UTC
Please describe the problem:
Every time any gtk based app now opens a file selection window, it takes about
15 seconds to come up (on a T40 Thinkpad, Pentium M 1600 Mhz processor with 512
MB of ram), during which time it is causing massive ammounts of disk io (I can
here the drive chunking) and CPU utilization is peeked at 100%.  This is *at
least* 5 times slower than the old file selection window took.

I have a large number of items in my home directory, which I'm sure is why it
takes a long time, but it is very bothersome that something which worked rather
efficiently in previous versions of GNOME/GTK regressed so heavily.

Even if the file browser defaults to another (smaller) directory (like when
saving multiple files through mozilla) it takes the same ammount of time, which
implicates either very bad startup time in general, or the fact that it is
running stat calls throughout my entire home directory even though I'm not
trying to save to that.

It would be really nice if performance was more on par with the previous file
browser, such a huge wait time for bringing up the widget is making it nearly
unusable.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Matthias Clasen 2005-06-16 14:48:43 UTC

*** This bug has been marked as a duplicate of 166601 ***