GNOME Bugzilla – Bug 425368
Using location bar in directory with many file is very slow
Last modified: 2018-04-15 00:19:31 UTC
If you use the file chooser from >=2.8 in a directory with a large number of files (e.g. more than 1500) and open the location bar then the chooser become unresponsive for a long period. I've done a bit of profiling using sunstudio (on solaris) and it seem to spend a lot of time in the splay() operations (about 40%) while it's building up the completion list for the chooser entry. In my experiments using a directory with 4000 files it took 50cpu seconds to create the dialog and populate the chooser entry completion list (once populated the completion list operated quite well). Almost all of the time was used in the gtkfilechooserentry.c::files_added_cb() and subfunctions. I've used gtk+-2.10.6 and gtk+2.10.11 and had the same (or similar) behaviour.
Created attachment 85683 [details] A very simple and naive program to launch a file chooser in a directory with lots of files This was my testcase program. I know it's very simple, but it was enough for me to gather the data. If you want some profiling results from sunstudio then let me know and I'll see what I can do.
Does the patch attached to bug 368931 improve things?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
I no longer use GTK and don't have a convenient environment to test. I don't care about this issue, so happy for it to be closed.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new