EmacsのConsultパッケージにおける非同期検索が遅く感じる理由と高速化の方法

Consult Emacsパッケージは、consult-fd、consult-find、consult-grep、consult-git-grep、consult-ripgrepなどの非同期検索コマンドを提供します。 これらのコマンドについて、Consultはミニバッファの入力が変更されるたびに必ずしも新しい検索を開始するわけではありません。代わりに、非同期プロセスを開始するタイミングを制御するために設定可能なデバウンス遅延とスロットリング遅延を使用し、別のリフレッシュ遅延が非同期結果を完了UIにプッシュする頻度を制御します。 初めてConsultを試したとき、Counselと比較して遅いと感じました（Emacsの設定であるshow-paren-delayについても同様の感覚がありました）。Counselでは、キーストロークごとに結果が即座に更新されましたが、Consultはリストを更新する前に0.5秒ほどためらうように見えました。結果として、この動作は完全に意図的なものです。現在のConsultのデフォルトは意図的に保守的です。 アグレッシブな非同期検索 低レイテンシと速度を優先する場合、これらの変数をよりアグレッシブに設定できます。 (setq consult-async-input-debounce 0.05 consult-async-input-throttle 0.1 consult-async-refresh-delay 0.05) これらの値は、Consultが非同期プロセスを開始するまでの時間を短縮し、完了UIがより頻繁にリフレッシュできるようにします。これらの値は、基盤となる検索プログラムの実行速度を速めるものではありません。ripgrepのような外部ツールは、すでに高度に最適化されたマルチスレッドアルゴリズムを使用して、複数のCPUコアでファイルをスキャンしています。代わりに、これらの変数はEmacs自体のフィードバックループを高速化します。Consultが外部プロセスを起動するまでの待機期間を短縮し、Emacs UIが新しい非同期データをプルして画面をより高速に再描画するようにします。 変数: consult-async-input-debounce (setq consult-async-input-debounce 0.05) この設定は、最後のキーストロークから0.05秒後にConsultが非同期プロセスを起動するまで待機させます。これは固定のポーリング間隔ではなくデバウンス遅延として機能するため、新しい入力があるたびにタイマーがリセットされます。検索は、完全な無音期間が経過した後にのみ実行されます。これにより、入力する各中間文字に対してEmacsが冗長なバックグラウンドタスクを起動するのを防ぎ、CPUオーバーヘッドを最小限に抑え、UIの応答性を維持します。 変数: consult-async-input-throttle (setq consult-async-input-throttle 0.1) consult-async-input-throttle変数は、Consultが非同期プロセスを開始できる頻度に対する厳密なレート制限として機能します。この値では、どれだけ速く入力しても、0.1秒ごとに最大1回新しいプロセスが開始されます。 この2つの概念の違いを分解すると、デバウンスはアイドルタイマーです。これは、ユーザーが入力するのを待機します。キーを押し続けると、タイマーはリセットされ続け、検索は入力が停止するまで実行されません。スロットリングは厳密な速度制限です。これは最大実行レートを強制します。単語間に一時停止してデバウンスタイマーを常にトリガーするのに十分な長さであっても、スロットリングはシステムが許可されたレートを超えないことを保証します。 変数: consult-async-refresh-delay (setq consult-async-refresh-delay 0.05) consult-async-refresh-delay変数は、Consultが非同期コマンドからの結果を完了UIにどのくらいの頻度で更新するかを制御します。この値により、Consultは新しい結果が更新を必要とする場合に、0.05秒という短い間隔でリフレッシュします。表示する新しいものがない場合にEmacsが継続的に再描画されるわけではありません。低いリフレッシュ遅延は検索結果をより速く表示できるようにしますが、再描画自体にはコストがかかります。Emacsの再描画は非常にコストが高いため、頻繁な更新はCPUおよびガベージコレクションのアクティビティを増加させる可能性があります。 値の選択 非同期検索を可能な限り応答性の高いものにしたい場合は、これらの値が低い入力レイテンシとリソース使用量の間の良好なバランスを提供します。Consultはミニバッファの変更に迅速に応答し、最小限の遅延で完了UIを更新します。これらの設定は、電源に接続された高速コンピューターに適しています。ラップトップでは、アグレッシブなプロセス作成と継続的なUI更新により、CPUがアクティブになり、保守的なデフォルト値よりもバッテリーが速く消耗します。低速なコンピューターや非常に大きなプロジェクトを検索する場合、デフォルト値は入力が変更されている間に不要な検索を回避することで、より良いバランスを提供する可能性があります。 最適な値は、タイピング速度、プロジェクトサイズ、検索ツールのパフォーマンス、電力制約、およびEmacsでの非同期結果の処理と再描画のコストに依存します。したがって、遅延を低くすることは、より少ない入力レイテンシとより頻繁な非同期作業の交換として明示的に見なすのが最善です。 関連投稿: 特定の発生時にEmacsがデバッガに入るのを防ぐ compile-angel Emacsパッケージ: Emacs Lispライブラリのバイトコンパイルとネイティブコンパイル ultisnips-mode.el - Ultisnipsスニペットファイル（*.snippetsファイル）を編集するためのEmacsメジャーモード easysession.el: Emacsセッション（ウィンドウ、タブバー、ファイルバッファ、スクラッチ、Dired、ナローイング、間接バッファ/クローン、Magitバッファなど）を簡単に永続化および復元できます。堅牢なdesktop.elの代替です。 Eglot for Python Development in Emacs: python-lsp-server (pylsp) をリンターおよびフォーマッターと統合する 効率的なソフトウェア開発とテキスト編集のための必須Emacsパッケージ quick-fasd.el - Emacsでの高速ファイルおよびディレクトリナビゲーションのためにFasdを統合する Eglot for Better Performance and LatencyのEmacs設定 Consultの作者でありメンテナーであるMinadは、GitHubリポジトリminad/consultのIssue #951で次のように述べています。 設定について：「デフォルト値は、測定に基づいた科学的な方法で決定したわけではありません。実際の測定による詳細な分析は、確かに高く評価されます。いくつかの選択は理にかなっています：consult-async-input-debounceは、タイピング速度に大まかに対応するはずです。さらに、consult-async-input-throttleは、デバウンス遅延よりもわずかに大きく選択されています。3番目の変数consult-async-refresh-delayは、他の2つとは独立しています。Emacsの再描画はコストがかかるため、1秒間に10回以上実行したくないでしょう。」 デフォルトについて：「デフォルト値は、バッテリーを節約し、CPUとGCの負荷を軽減するため、優れています。はい、何かを入力した後には遅延が発生します。検索を早すぎず開始しないことで、無駄な検索を開始せずに、すぐに中断されることになる入力を完了できます。私の意見では、ここではあまり時間を失いませんし、表示のリフレッシュは、より落ち着いた、より邪魔にならない方法で行われます。Emacsは高価な割り当てを伴う最もパフォーマンスの高い言語ランタイムではないことを考えると、最終的には時間を節約できるとさえ主張できます。Emacsメモリシステムへの圧力を減らすことは、ガベージコレクションのアクティビティとスタッターを回避するのに役立ちます。」