Preventing gtk FileChooserDialog calling stat on all files in the directory?

views:

232

answers:

+1 Q:

Preventing gtk FileChooserDialog calling stat on all files in the directory?

Opening a gtk FileChooserDialog is painfully slow for nfs directories containing many files. strace shows a lot of time calling "stat". About 5 calls for each of the files in the directory. How can we switch off the calls to 'stat' and just show a list of filenames without the modification time?

We're using operating Redhat enterprise 4, x86_64, Linux 2.6.9-42.0.8.ELsmp and FileChooser is coming from: /usr/lib64/libgtk-x11-2.0.so.0.400.13 . A test program opens a FileChooserDialog and takes 10 seconds to appear, compared to about 25 ms for 'ls' to list the same directory.

Our eclipse application being crippled by this file selector issue...

Is the directory mounted noatime? That may help with the stat since the atime for each file will be updated with the stat.

You'll need to remount the nfs mount with -o noatime in order to turn off atime updating.

2009-05-01 16:07:12

cat /proc/mounts shows: nfs rw,v3,rsize=32768,wsize=32768,hard,intr,tcp,lock,addr=gx.hidd.en 0 0So no? We tried chattr and got "Inappropriate ioctl...". Can we change this 'noatime' from a user account when our application runs?Using 'ls' | head takes 40 milliseconds, compared to 10 seconds for a GTK file selector. The problem is GTK is doing something which is not needed and not wanted and we'd prefer to stop that altogether instead of making it less slow.Thanks a lot for your suggestion - I shall forward it to the sysadmins...

Jon 2009-05-01 17:00:22

The GTK file open dialog is most probably stat(2)ting all files in the directory. It is an eqivalent of ls -l on the directory, and it should run about that slowly. The output of ls | cat (which is significantly faster) might not be enough, because that one cannot distinguish files from directories.

I'd suggest measuring ls | cat, ls -l and and the GTK file open dialog. If the GTK file open dialog is a lot slower than ls -l, then there is something wrong with GTK (not NFS). I'd run the GTK application through strace, and see what is slow. If the GTK file open dialog has about the same speed as ls -l, I don't think it can be made faster -- perhaps NFS mount flags can be tweaked, NFS clients and servers upgraded, or it is possible to switch to a faster infrastructure such as Samba.

pts 2009-05-01 21:53:03

ls -l is also slow, so the underlying problem is how to navigate on a dodgy file system. The point is, I don't care whether the 14027 files which I can't see in a file selector are directories or not, I only need to know for the first 20 or so that fit on the screen.

Jon 2009-05-02 07:44:38

+2 A:

The gtk+ and gnome team have a bug report related to this issue, at least since 2005. Recent and future changes in the gnome core libraries will hopefully improve the performance. This issue can be aggravated if you have any bookmarks to network drives in the filechooser menu.

rsarro 2009-05-12 23:00:54

ansaurus

tags:

views:

answers:

Preventing gtk FileChooserDialog calling stat on all files in the directory?

related questions