Hi,

a few people have claimed that opening the file chooser dialog would take a considerable amount of time if it is opened in a directory with lots of files. While I have myself observed this behaviour in the past, I haven't been able to reproduce it for a while. I have tried with GTK+-2.6.2, GIMP 2.2.3 and current CVS. The folder that I tried this with has close to 2000 image files and a couple of directories. The file-chooser dialog opened in less than a second which I think is a reasonable delay.

If anyone sees this problem and updating to gtk+-2.4.14 or gtk+-2.6.2 doesn't solve it, I'd like to hear about a way to reproduce it. We would have to check whether it's a GIMP or a GTK+ problem and either take care of it or delegate the solution.

Sven

Hi,

writes:

After updating to debian's "2.6.2-2", I made a few tests (with gedit, though, which should have similar performance).

Are you using the gnomevfs file-chooser backend of the or the one that comes with GTK+? That would be a rather important detail about your system.

The symptoms you describe sound like a weakness of GtkFileSystemUnix, or even the xdgmime implementation that it is using. One thing you could try is to move away /usr/share/mime/magic. If that file is not available, no magic probing should be performed on your files. It would also be a good idea to look at gtk+/gtk/xdgmime/xdgmime.c. There's a FIXME in that code that looks somewhat related.

strace'ing gedit shows that the only change seems to be that instead of reading 128k of every file, only 8k is being read. One obvious problem is that it first stat's all files _then_ reads them, which is quite inefficient even for local filesystems.

Are you sure that it reads _every_ file? That doesn't sound like you are using xdgmime since that would only open the file if it can't determine the filetype from the extension. You are probably using gnomevfs and there have been quite some performance improvements been done to this code lately. Perhaps try a more recent version of libgnomeui?

I also did not quite understand the comparison you did above. What application is it that reads 128k of every file and which one reads only 8k of data?

However, the detected content types are not even being displayed. Seemingly, they are not used at all, so the obvious improvement, as for the gimp file save dialog, would be to not gather costly data that is not being used or displayed (at least by default).

Sorry, but the MIME types are being used to choose the icons to display in the file list so you cannot argue that the information would not be used at all. I agree though that I would prefer a fast MIME type detection over a more accurate one. Using filename extensions should be good enough here.

Nevertheless, this is all supposed to happen asynchronously. There is probably a bug in that code but here's what the file dialog is supposed to do when you change folders:

1. starts a 0.5 second timer 2. slurps as much of the folder as it can 3. if the timer triggers, the model is set on the treeview; subsequent files are added as they come in 4. if it finishes loading before the timer triggers, the model is set on the treeview

If the current path is not the same as the path for set_uri(), then it remembers the uri you want, changes folders, and selects the uri when it finishes loading the folder.

(This is based on an excerpt from a discussion we had yesterday in the gtk+ developers meeting.)

There's a bug report about file-chooser performance problems but I am not quite sure if you are actually seeing the same problem. Bug #166601 (http://bugzilla.gnome.org/show_bug.cgi?id=166601) appears to be a problem in the gnomevfs file-chooser backend. What you said about your strace doesn't seem to fit the straces attached there. But I haven't looked at the straces in all detail yet.

Sven