ノーチラスが遅いのはなぜですか？

たくさんのファイルを含むディレクトリを開くときにNautilusが非常に遅いのはなぜかと思います。たとえば、私の/ usr / libディレクトリには1900個のファイルがあり、すべてを表示するには約5秒以上かかります。数ヶ月前にUbuntuをインストールして以来、このようになっており、時々非常に迷惑です。強力なハードウェアは持っていませんが、Windows Explorerはこれよりもはるかに高速であることを知っています。

高速化するためにできることはありますか？

Ubuntu 10.04

の実行を追跡するnautilusと、遅延が2つの要因の組み合わせによるものであることがわかります。

• 各ファイルに関する有用な情報を表示するのは賢明です。ファイルの内容を調べて、使用するアイコンを決定し、場合によってはプレビューを表示します。これは、環境設定でプレビューをオフにすることで調整できます。

• 多くの役に立たない作業をstat行います（各ファイルを複数回実行し、/proc/filesystemsディレクトリ以外でもチェックするなど）。プログラミングを学び、プログラムを改善し、パッチを送信するだけです。または、少なくとも作成者に機能要求を送信します（より速くしてください）。

• 各ディレクトリに対していくつかの外部プロセスを呼び出しますが、それらが何をするのかについては調べていません。

[編集]-> [設定]の下の[プレビュー]タブで、すべてのオプションを[なし]に切り替えてみてください。

また、「支援技術」をオフにするのに非常に役立ちました。これは、「システム->設定->支援技術」で実行できます。「支援技術を有効にする」のチェックを外します。

後者の変更を有効にするには、ログアウトして再度ログインする必要があります。

これは、 NautilusやGVFSを含む他のプロジェクトの主任開発者であるAlexander Larssonとの話を思い出しました。

Giles の答え、特にNautilusがファイルの内容を調べていることについては、Nautilusが「遅い」という主な理由に触れています。しかし、Gilesは、なぜこれが遅いのかを説明していません。アレックスの発言は次のとおりです。

白紙の状態から始めて、ファイルシステムにまったくアクセスしていないとしましょう。stat（“ / some / dir / file”）を実行するとします。まず、カーネルはファイルを見つける必要があります。技術的には、このファイルはiノードと呼ばれます。まず、ルートディレクトリのiノードを保存するファイルシステムスーパーブロックを調べます。次に、ルートディレクトリを開き、「some」を検索し、それを開き、「dir」を検索します。最終的にファイルのiノードを検索します。

次に、iノードデータを実際に読み取る必要があります。最初に読み取った後、これもRAMにキャッシュされます。したがって、読み取りは1回だけ行う必要があります。

HDを古いレコードプレーヤーのように考えてください。針を使って適切な場所に移動すると、回転しながらものをすばやく読み続けることができます。ただし、「シーク」と呼ばれる別の場所に移動する必要がある場合は、非常に異なることを行っています。腕を物理的に動かしてから、正しい場所が針の下になるまで大皿が回転するのを待ちます。この種の物理的な動きは本質的に遅いため、ディスクのシーク時間はかなり長くなります。

だから、私たちはいつを求めるのですか？もちろん、ファイルシステムのレイアウトに依存します。ファイルシステムは、読み取りパフォーマンスを向上させるためにファイルを連続して保存しようとします。また、一般に、互いに近い単一ディレクトリのiノードも保存しようとしますが、すべてはファイルの書き込み時、ファイルシステムの断片化などに依存します。ケースでは、ファイルの各ステータスがシークを引き起こし、ファイルを開くたびに2回目のシークを引き起こします。そのため、何もキャッシュされていない場合、物事に非常に長い時間がかかるのはそのためです。

一部のファイルシステムは他のファイルシステムよりも優れているため、最適化が役立つ場合があります。アプリでいくつかのことができます。たとえば、GIOはreaddir（）から受け取ったiノードをソートしてから、iノード番号がディスク順序と何らかの関係があることを期待して（通常は持っている）、前後のランダムシークを最小限に抑えます。

1つの重要なことは、シークを最小限に抑えるようにデータストレージとアプリを設計することです。たとえば、Nautilusが/ usr / binを読み取るのが遅い理由は、そこにあるファイルには通常、それぞれに対してマジックスニッフィングを行う必要がある拡張子がないためです。そのため、各ファイルを開く必要があります=>ファイルごとに1シーク=> slooooow。もう1つの例は、gconfのように多くの小さなファイルに情報を保存するアプリですが、これも悪い考えです。とにかく、実際には、待ち時間を隠そうとする以外にできることはあまりないと思います。

彼は次のメモで終わりました。

このジレンマ全体に対する本当の修正は、回転するメディアから離れることです。Intel SSDは素晴らしいと聞きました。ライナスは彼らに誓います。

:-)

私はついにnautilusを非常に遅くしているものを見つけました：ブックマーク。

修正するには、すべてのブックマークを削除し、再起動してから、それなしでは生きていけないブックマークを追加し直します。

straceを使用して、nautilusがすべてのビューについて多くのファイルを記述していることに気付きました。トレース中に参照していたディレクトリにないファイルでさえも。nautilusはこれらのブックマークを事前にキャッシュしようとしていると思います。

ブックマークとして1つのネットワークドライブがありました...これが、nautilusのロードに数秒かかった理由である可能性があります。

Thunarなどの代替ファイルマネージャーを使用してみてください。Thunarはディレクトリリストの読み込みがはるかに高速で、NTFS usbハードドライブからext4へのファイルのコピーがより安定していますが、ファイルの大きなセットではNautilusのような問題があるようです。

スイッチスクリプトhttps://help.ubuntu.com/community/DefaultFileManagerのリンクを次に示します 。

Gnomeシステムにxfceがインストールされていて、使用しない場合は、exo-utilsを削除してください

Chromeがダウンロード後にファイルを正しく開かないという問題とともに、私の問題を修正しました。

[編集]-> [設定]の下の[プレビュー]タブで、すべてのオプションを[なし]に切り替えてみてください。

また、「支援技術」をオフにするのに非常に役立ちました。これは、「システム->設定->支援技術」で実行できます。「支援技術を有効にする」のチェックを外します。

後者の変更を有効にするには、ログアウトして再度ログインする必要があります。