高速なターミナルについて自分が間違っていたこと

 (mijndertstuij.nl)
3 ポイント 投稿者 GN⁺ 7 일 전 | 1件のコメント | WhatsAppで共有
  • 高速なシェル構成は最小限の設定だけで実現されるものではなく、最新の Zsh ツールは 体感上の起動速度 を別の方法で改善する
  • time zsh -i -c exit は初期化と終了時間をまとめて計測するが、実際にユーザーが待つのは 最初のプロンプト、最初のコマンド実行、入力遅延である
  • zsh-bench は最初のプロンプト時間、最初のコマンド実行時間、コマンド遅延、入力遅延のような実際の体感項目を測定する
  • プラグインマネージャーが常に遅いわけではなく、antidote はプラグイン一覧を単一の静的スクリプトにコンパイルし、起動時に依存関係を解決しない
  • 最小構成は高速化の唯一の道ではなく、理解しやすい単純さ のための選択であり、機能を備えたシェルも即応的に感じられる

何を間違って測定していたのか

  • time zsh -i -c exit は対話型シェルを起動したあと即座に終了する方式で、全体の初期化時間と終了時間をまとめて測定する
  • この方式はよく使われるベンチマークだが、zsh-bench ではこの方法が誤っている理由を別セクションで扱っている
  • 実際にユーザーが待つのは全体の初期化時間ではなく、プロンプト表示、最初のコマンド実行、その後のすべてのキー入力の遅延である
  • ある設定はこのベンチマークでは遅く見えても、実際の使用ではより速く感じられることがある
  • zsh-bench は最初のプロンプト時間、最初のコマンド実行までの時間、コマンド遅延、入力遅延を測定する
  • instant prompt はシェル起動時にキャッシュされたプロンプトを描画し、.zshrc 完了前でも入力を可能にする
  • instant prompt が適用されると、初期化コストに関係なく体感上の起動時間はほぼ 0 に近くなり、終了時間の数値の重要性は下がる

プラグインマネージャーと構文ハイライトに関する訂正

  • 「プラグインマネージャーはオーバーヘッドを増やす」という表現の範囲が広すぎた

    • 一部のプラグインマネージャーは、起動時に独自のオーバーヘッドと依存関係の解決を追加する
    • しかし、この特性をプラグインマネージャー全体のカテゴリに当てはめたのは不正確だった
    • antidote はプラグインの単純な一覧を単一の静的スクリプトにコンパイルし、シェルを開くときに依存関係を解決しない
    • antidote の方式は、手書きの source 行のように生成された 1 つのファイルを source する構造である
    • より正確な区別は、起動のたびにプラグインを解釈する重いフレームワークは遅く、最新の静的バンドリング型マネージャーはそうではない、という点にある
    • 最新の静的バンドリング型マネージャーは更新管理も提供するが、自作のインストールスクリプトではこれを手作業で処理することになる

  • 遅い構文ハイライターを勧めてしまった

    • 入力遅延を扱う設定で zsh-syntax-highlighting を source したのは、あとから振り返ると恥ずかしい選択だった
    • zsh-syntax-highlighting はキー入力のたびにバッファ全体を再ハイライトするため、長いコマンドラインではまさにそのキー入力ごとの遅延を生むことがある
    • Zsh-patina はより新しいアプローチであり、長いコマンドを入力する場合、現在使っているツールよりも良い体感をもたらす可能性がある

  • 残る主張の核心

    • .zshrc 全体を一度に読めることが、実際に好まれている部分である
    • フレームワークが代わりに決めず、選んでいないプラグインが存在しないことが重要である
    • 構成要素が少ないため、遅い部分が生じたときに見つけやすい
    • この選択は速度そのものよりも単純さへの好みであり、単純さが高速さにつながるのは副次的な効果である
    • フル機能のシェルでも高速で即応的に感じられ、その目標に到達する方法は複数ある
    • 最小構成を維持するのは、高速化の唯一の道だからではなく、自分で理解していたいからである

  • 結び

    • 元の記事は、この文章を指すメモが冒頭に付いた状態でそのまま残されている
    • 設定は引き続き dotfiles にあり、構文ハイライターもそのまま残っている
    • 一部の設定は、より新しいツールを使うよう更新される予定である

関連記事

1件のコメント

 
GN⁺ 7 일 전
Lobste.rsの反応

  • コミュニティとアイデア交換の力を示す良いフォローアップ記事で、インターネットを少しだけ人間的に感じさせてくれる

  • 間違いを認めて修正できることにまず驚いた、という反応
    真面目な話、新しいシェルの多くはあまり好きではないので最初の記事は読み飛ばしたが、今回の記事は良かった。ashはデフォルトの履歴動作が自分の使い方に合わず、fishのようなシェルは興味のないUI機能が過剰だと感じた
    ただし自動プロンプトキャッシュのような機能は良さそう。自分でも怪物みたいなプロンプトを作って雑にキャッシュしたことがあるので、なおさら実感がある

  • こういう記事は良い。もっと多くの人がミスとその後の訂正を公開すれば、インターネットはもう少し人間的な場所になる

    • 筆者です。ありがとう。特にチームの手本になるために、ミスを認めることを継続的に実践しようと努めている

  • 最初の記事を見て、すでにzshrcを最適化して時間を半分に短縮した。その後さらに調べてzsh-benchも使い、あの記事が最適化のきっかけになった

  • もうメンテナンスはされていないが、zsh4humansは性能面では最先端にかなり近い。作者は一種のZshの天才のように思える
    自分では使っていないが、制御権を保ちたいからだ。それでも理解できる部分では、transient promptのようなアイデアを取り入れている
    zsh-benchも同じ作者のプロジェクトだとは知らなかった

    • いい情報だ。zsh4humansプロジェクトには本当に宝石のような部分がありそうなので確認してみる

  • この記事のおかげでzsh-patinaを知った
    数年間zsh-fast-syntax-highlightingを使ってきたが、この新しいツールも評価してみたい

  • zsh-syntax-highlightingがキー入力のたびにバッファ全体を再ハイライトして遅延を生むという話が、実際に目に見えて分かるものなのか気になる
    コードエディタでも本質的には似たようなことをしているのに、遅延はほとんど感じたことがない。コマンドラインはエディタ基準で見れば「長い」コマンドでもたいてい短いので、問題になるというのは意外だ
    ただ、構文ハイライトが思ったよりはるかに複雑なら、そういうこともあり得る

  • この記事から新しいコツをたくさん学んだ。これまではプロンプトに入るデータが遅いバックエンドから来ないようにする程度の単純な修正しかしてこなかった
    ここでははるかに細かなプロンプト最適化が扱われていて、ターミナルを数え切れないほど開く日常的なワークフローでは、こうした小さな改善が積み重なって大きな影響を与える