Open dialog populates slowly

Hey guys,
 This started getting "slightly" better however, after todays updates, Tuesday April 7,2009, it is back to being very slow again.
 i have read bugs about this for Debian as well,, so maybe a Gnome problem?
 None the less , it is not easy to open all my apps via terminal with sudo , which is the only way it works properly

coz

System configuration: MSI P6N SLI Platinum motherboard, E6600 Core 2 Duo o/c to 3.125 GHz, 2 GB OCZ Rev 2 Platinum DDR2 SDRAM, EVGA GeForce 8800 GTS w/640MB, 320GB x2 SATA RAID1, Ubuntu 9.04 x86

I did not have this problem in 8.10, but have it bad in the 9.04 Ubuntu final release with ext3 file system. When any program needs a file dialog, it takes 20-25 seconds to appear at all, but it is fully populated when it appears. The underlying application even grays out while waiting. A reboot fixes it temporarily. I'm trying to see what may cause the issue, but haven't discovered the trigger yet. Everything else, including file managers, seems to work fine. It's only the file dialogs that lag so badly. This really needs to be fixed and soon.

Additional data: System Monitor does NOT show a spike in CPU activity while waiting for the file dialog to appear, but just before it does appear, Xorg goes to 20% for less than a second then drops back to zero. Using iotop, no disk usage appears for most of the delay period, but kjournald jumps in with a couple of disk writes towards the end of the delay. Sometimes a system log does as well, but not most of the time.

I am currently exploring if the slow open/close file dialog issues is related to VMWare services. When I upgraded to Ubuntu 9.04, those kernel modules required recompilation. The slow dialogs immediately followed that. I restarted the computer and the slowness disappeared, and I thought that was the end of it. I just ran a virtual machine, and although the file dialogs were slow at first, they have returned to normal. Still not sure what's causing them.

Verified. Running AMD64 9.04 (upgraded from 9.04 beta and RC). I've taken additional steps to attempt to resolve this:
1) I uninstalled Tracker.
2) I completely wiped-out my profile (and thereby any add-ons)
3) I disabled all file previews in Nautilus.

My results are the same. As a non-privileged user my firefox open dialog takes a SOLID 5 seconds from CTRL+O to a useable dialog. As root, it takes 2.5-3.0. Though that is still ridiculous, its more acceptable.

I've also noticed that once the dialog comes-up, it has previews of the files in the directory, regardless of the setting in nautilus... I'm wondering is there a way to disable file previews in FireFox?

system specs: HP nx9420 laptop with Core2 Duo T7400 @ 2.16ghz, 2gb ram, nVidia GeForce Go 7900 GTX, SATA2 hard disk... its not a performance problem.

More environment info: I am running compiz, I do not run any gnome-panels. I run gnome-do with the docky theme and desklets. Every other application on my system seems to run dandy and the open dialog works smashing.

Cheers,
-C

Hey guys,
 i can confirm this slow open dialog problem. In terminal i get this when running gimp and trying to open a file from the File/Open menu;

(gimp:4196): Gtk-CRITICAL **: gtk_tree_sortable_set_sort_column_id: assertion `GTK_IS_TREE_SORTABLE (sortable)' failed

I have to say that I have both kde and gnome installed and it is slow in both.
No matter which application I try to open a file location ..it has taken up to one minute to populate the open dialog

sounds like januty near the release :)

coz

hey guys I just wanted to add that any dialog even from the menu are slow to open example righit click desktop and any option with sub menu is slow to open

coz

I can corroborate .. I notice this OpenOffice mostly - but that's probably because I open and save documents from there a lot - but have just noticed in Konqueror too.
It's not just slow coming up the first time - although that is disconcerting - but in all operations: change directory, clicking on file name to select it (for open), even accessing the icons along the top. Every operation takes approx 8 seconds. In home directory, so there shouldn't be any slow network resources being accessed. Settings in the dialog sort: by name; view: short list, Aside preview: off. I would have thought this is the fastest available.
Karmic 64 bit, Asus M51S (2.4Ghz dual-core), 3 GB RAM and only OpenOffice open - not a heavy load by any stretch of imagination.

Same here. I still use Hardy (32bit) because of KDE3. The behavioris exactly as Bob described.

I have the latest Gimp from getdeb installed (2.6.6.). But no matter what GTK-app is use (handbrake, gscan2pdf were tested), it's slow everywhere with every single action in this window.

Important maybe: In directories without any images or videos it's quite fast. The more images the worse. One or two images are enough to make in unusable. That is all without any image-previews activated anywhere.

KDE/QT-stuff is not affected here, just the GTK-dialogs.

Problem is here with my system,, too. Just to comment on Tanker Bob 's comment(comment #4), when I am waiting for the dialog to populate, I see the CPU consumption is 100% for one core. I have an old Pentium-D dual core system. And my problem is reported with launchpad bug #517410..

Not sure why this is marked as dupe - Bug #517410 is logged against "tropical" - I don't even know what tropical is and it is not mentioned in the OP or comments here at all. It also has nothing to do with Gnome as I and my wife both are driven nuts by this problem and we are both running KDE (it might however have something to do with GTK). It has been a problem since Ubuntu 8.10 at least. Of course it is possible there is more than one cause for slow open file dialogs! My experiences have nearly all been with OpenOffice.org - which is far more likely to be related to Bug #424132, although that has such an encompassing title that multiple problems are getting reported in the comments (scroll down for mention of slowness, they are definitely seeing this same problem)

Further .. I can only speak for the symptoms I am seeing of course, but I hunted around looking for related bug posts.
My problem is quite probably this: https://bugzilla.novell.com/show_bug.cgi?id=579795 - it's reported in OOO 3.2 but that doesn't mean it didn't occur in earlier versions (and I'm currently Karmic/OOO 3.1, think I saw this behaviour in Jaunty too)

Also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479778 "libgtk2.0-0: Open dialog very slow"; https://bugzilla.gnome.org/show_bug.cgi?id=425368 "Using location bar in directory with many file is very slow" although in my case I can have slowness in any directory even if there are no files in it, and the CPU is not working.