Hi,
<pcg@xxxxxxxx ( Marc) (A.) (Lehmann )> 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
