gtk2 file chooser slow

[Alec Warner]

2. What did you attempt to do, or what did you notice was wrong?
I'm attempting to upload a large numbers of files in a browser (I tried both chrome and firefox). I tried uploading 600+ files to Google drive and it hangs on the upload screen for 2-5 minutes before starting the upload. It appears that the bottleneck is getting the list of files from the file chooser to the browser to start processing, not in the actual upload process it self.

3. What was the expected result, or the expected state?
It should exit the upload screen quickly and start the upload

I'm running into this issue on a Precise desktop. It's not exhibiting the behavior on Lucid desktops.

The project that I'm working on requires uploading hundreds of files at once and has worked fine on Lucid. Now that I've switched to Precise I am unable to work or iterate quickly, incurring 5-10 minute penalties after every code change I make. It's a major work stopping issue for me.

DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.1 LTS"
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04

stracing reveals:

open("/usr/local/google/home/dmillett/.local/share/recently-used.xbel.OB5WNW", O_RDWR|O_CREAT|O_EXCL, 0666) = 84
fcntl(84, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(84, {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f43cd6ae000
lseek(84, 0, SEEK_CUR) = 0
write(84, "<?xml version=\"1.0\" encoding=\"UT"..., 8114176) = 8114176
write(84, "cation name=\"Google Chrome\" exec"..., 1234) = 1234
fstatfs(84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=105852516, f_bfree=49581834, f_bavail=44283402, f_files=26492928, f_ffree=24427833, f_fsid={-1302100876, 32001381}, f_namelen=255, f_frsize=4096}) = 0
lstat("/usr/local/google/home/dmillett/.local/share/recently-used.xbel", {st_mode=S_IFREG|0600, st_size=8115410, ...}) = 0
fsync(84) = 0
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
close(84) = 0
munmap(0x7f43cd6ae000, 4096) = 0
rename("/usr/local/google/home/dmillett/.local/share/recently-used.xbel.OB5WNW", "/usr/local/google/home/dmillett/.local/share/recently-used.xbel") = 0
madvise(0x7f43d99eb000, 8388608, MADV_DONTNEED) = 0
chmod("/usr/local/google/home/dmillett/.local/share/recently-used.xbel", 0600) = 0
--- SIGPROF (Profiling timer expired) @ 0 (0) ---

There are thousands of these files (one for every file the user tried to upload...) and it makes her experience very bad. She ended up following some instructions at http://cviorel.easyblog.ro/2012/03/07/disable-recent-documents-in-gtk2gtk3/ to disable 'recent files.' However it might be nice if this worked better for this use case. The user claims she routinely uploads 14000+ files to google drive, using her web browser.

-A

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1080890/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

[Timothy Arceri (t-fridey)]

Chrome and Firefox still use GTK+2

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Esokrates (esokrarkose)]

I can absolutely confirm this issue. For example, it does not matter which gtk file manager you use, they are all very slow for opening large directories (even on ssd) with many files (For Qt based filemangers as dolphin, this is not a problem). For example take nautilus and try to open /usr/lib or /usr/bin. This takes much too long. Every gtk application (it does not matter if gtk2 or gtk3) I have tried so far is very slow at browsing files. This has been reported so many times (in most of the cases for nautilus) and still the situation has not changed.