gtk FileChooserDialog がディレクトリ内のすべてのファイルに対して stat を呼び出すのを防ぎますか?
-
03-07-2019 - |
質問
多くのファイルを含む nfs ディレクトリでは、gtk FileChooserDialog を開くのが非常に遅くなります。strace は、「stat」の呼び出しに多くの時間を費やしていることを示しています。ディレクトリ内の各ファイルに対して約 5 回の呼び出し。「stat」への呼び出しをオフにして、変更時刻を表示せずにファイル名のリストだけを表示するにはどうすればよいでしょうか?
Redhat enterprise 4、x86_64、Linux 2.6.9-42.0.8.ELsmp を使用しており、FileChooser は次のものから来ています。/usr/lib64/libgtk-x11-2.0.so.0.400.13 。テスト プログラムが FileChooserDialog を開き、表示されるまでに 10 秒かかります。一方、「ls」が同じディレクトリを一覧表示するのに約 25 ミリ秒かかります。
このファイルセレクターの問題により、Eclipse アプリケーションが機能しなくなります...
解決
gtk +およびgnomeチームには、この問題に関連するバグレポートがあります、少なくとも2005年以降。gnomeコアライブラリの最近および将来の変更により、パフォーマンスが向上することが期待されます。 filechooserメニューにネットワークドライブへのブックマークがある場合、この問題は悪化する可能性があります。
他のヒント
GTK ファイルを開くダイアログは、ディレクトリ内のすべてのファイルを stat(2) している可能性があります。それは以下と同等です ls -l
ディレクトリ上にあるので、それくらいゆっくりと実行されるはずです。の出力 ls | cat
(これは大幅に高速です) では、ファイルとディレクトリを区別できないため、十分ではない可能性があります。
測定することをお勧めします ls | cat
, ls -l
そして GTK ファイルを開くダイアログが表示されます。GTK ファイルを開くダイアログの速度がはるかに遅い場合は、 ls -l
, の場合、GTK (NFS ではなく) に問題があります。GTK アプリケーションを実行します。 strace
, 、何が遅いのかを確認します。GTK ファイルを開くダイアログの速度がほぼ同じである場合は、 ls -l
, 、これ以上高速化できるとは思えません。おそらく、NFS マウント フラグを調整したり、NFS クライアントとサーバーをアップグレードしたり、Samba などのより高速なインフラストラクチャに切り替えることは可能です。
ディレクトリはnoatimeにマウントされていますか?各ファイルのatimeは統計情報で更新されるため、これは統計情報に役立ちます。
atime更新をオフにするには、-o noatimeでnfsマウントを再マウントする必要があります。