GNOME Bugzilla – Bug 302322
GtkFileChooser performance problems (aka let's do it again)
Last modified: 2005-06-09 18:15:26 UTC
The file chooser takes way too long to show up. It really should pop up right away, i.e., in less than 0.1s. We could do that 15 years ago in msdog, so it is not an unreasonable goal. Low-hanging fruit: 1. Don't stat every single file in the starting directory twice. Really. (I believe I have fixed that one before.) It would be nice to get a regression test for this problem. 2. If possible, don't stat using /full/path/names. In the hot-cache case that is N times slower than it should be where N is the number of path components. A lot more if non-local filesystems are involved.
Problem 1 can be seen by putting g_print ("%s: stat-ing \"%s\"\n", G_STRFUNC, fullname); into cb_fill_in_stats and running tesetfilechooser. This appears to be caused by fix the for bug 145470.
Created attachment 45801 [details] Gzip'd "truss -d" output Federico wanted an annotated strace, so there. All functions in filechooserdefault, filesystemunix, and pathbar got WHERE_ARE_WE; added, defined as... #define WHERE_ARE_WE int _dummy_ = access ("::" __FUNCTION__, F_OK)
See also bug #154394
Created attachment 45802 [details] Gzip'd "truss -d" output, take II ok, that got so slow that FOLDER_CACHE_LIFETIME was too small. (That does not trigger in real life.) I upped it. For the record, the trace is for running testfilechooser and pressing cancel.
I think we can mark this as a general duplicate of bug #166601.
Lets do it then... *** This bug has been marked as a duplicate of 166601 ***