GNOME Bugzilla – Bug 154394
gtkfilechooserbutton instantiation really slow
Last modified: 2013-09-23 21:00:47 UTC
When you add a (or some) GtkFileChooserButton(s) to a dialogue, it will slow the opening of the dialogue down; the more chooser buttons, the slower. This is because each GtkFileChooserButton instantiates one GtkFileChooserDialog, which scans the directory, which is slow.
Created attachment 32186 [details] extreme testcase as patch to testfilechooserbutton.c, adds 20 file chooser buttons instead of one
Is there a way to inhibit the GtkFileChooser dialog reading the directory contents until it's actually shown, as oppsed to when it's created?
I *think* that it reads the dir contents asynchronously now, but I could be mistaken...
GtkFileChooserDefault is what (needs to be?) changed in that case.
The proper fix for this bug (AFAIK) is to not create the GtkFileChooserDialog on construct, and basically do the same kinds of storage, validation, and signal emission until the user opens the dialog (via click or "Other") -- then copy the data over and free the data. It's a fairly large-sized job, since it'd basically mean: if (button->priv->dialog) do_via_dialog (); else do_via_button (); all over the place. Another memory-saver would include only keeping either the button or the combo-box in-memory at any one time, and sharing the GtkListStore (code, at least) for the shortcuts with GtkFileChooserDialog.
See also bug #166601 and bug #302322.
A few things: With the current implementation of both GtkFilesystemUnix and GtkFileSystemGnomeVFS, folder objects are singletons within a particular instance of GtkFileSystem. However, four chooser buttons mean four GtkFileSystem objects, or possibly more --- I don't think that GtkFileChooserDefault and GtkFileChooserEntry, for example, share the same GtkFileSystem object. A first patch would be to share the file system objects. A second patch would result after profiling why setup time is so large.
I think this is fixed with my patch to not do loading until ::map(). Can you please confirm? That patch is now in HEAD and gtk-2-8.
It seems usable now with a few filechooserbuttons, although it's still somewhat slow (but much better than when I last tried this) when you have really many of them (which shouldn't be a too common situation). I guess this bug can be closed now. If you're interested, I've updated my testfilechooserbutton patch to add a variable number of filechooserbuttons, @ http://www.gnome.org/~chpe/patches/many-filechooserbuttons.diff .
Chrisian: could you hack up a little program to create a window with a bunch of GtkFileChooserButtons, then destroy the window once it is mapped/exposed? And run that in a loop a few hundred times? And run sysprof on it? :) I'd love to see the results.
Dear hackers, Any news on this bug ? regards -- This message is brought to you by your beloved Bugs cleaning team,
Maybe bug #354887 is relevant? It's about FileChooserButton asking for authentication unnecessarily. Maybe the slowness is due to unnecessary network IO?
Marking as obsolete; we need new profiles.