アプリケーション・パフォーマンス

[アーカイブ済] 最終更新日によって Joe Schaefer 火, 28 4月 2026 ソース

多くの開発者は、パフォーマンスの最適化を考える罠に陥るのは、コードの各行をできるだけ効率的にすることです。、または彼らが見つけることができる最速のプログラミング言語でアプリ全体を書き込むことを選択。

実際にはその逆です。アプリケーションのアーキテクチャ上の制約から始めて、それらを使用して監視対象にドリルダウンします。”遅い” プログラムの一部。その部分の実装は、実行する必要がある他のすべてのパフォーマンスの選択をガイドします。その部品ほど低速ではないものは、それ以上最適化する必要はありません。代わりに、人間の表現と実装のシンプルさと明確さ、専門家以外の読者に焦点を当てるSSDLC あなたのプログラムの残りのコードのために、ソフトウェアの

あなたはこのプレイブックで反復することができますが、私のプロとしてのキャリアで3つの反復を超えて行く必要はありません。

そのため、次のようなエレガントなプログラミング言語を使用してください。Python3 または写本/タイプスクリプトそして、オープンソースの世界で主題の専門家(SME)があなたに力を与えますC/C++ 特別な目的のためのネイティブ結合。ビジネス・ロジックに対して行うことは、任意の動的プログラミング言語がすぐに使用できる**よりも高速である必要はありません。

依存関係のないバッシュ・スクリプトでも、多くの基本的なタスクを実行できるソリューションです。これは、Augmented Reality社の記事です。マジックリープ数年前、不器用さを取り替えるOpenGrok マルチプロセッサの並列化を利用するサービスxargs -Pおよびサポートコンピュータサイエンス簡単な検索エマックス/ヴィム バインディング

https://github.com/joesuf4/home/blob/wsl/bin/pffxg.sh

このスクリプトは、静的に型付けされたコンパイル済プログラミング言語で記述されたGitHubの通常の容疑者よりも高速です。ただし、ボトルネックの正確な特定謀殺する (大量のループ) フォーク+エクセク 真ん中の呼び出し、および使用xargs 代わりに、10行に実装されたコア・アルゴリズムを使用して、このスクリプトとよく似たスクリプトを取得します。シェル.

また、SMEのオープン・ソース・コミュニティは、他の方法ではなくスマートな方法で使用されています。”フィルタされた再帰的grep” GitHubに対する実装が実行されました。自分の(スレッド化された)実装を内部的に採用して維持する代わりに、見つける, xargsおよびgrep事前インストールされた他のSMEの実行可能ファイルを再利用するだけで、何十年にもわたって現状のまま完成しており、主に残りの部分にシェルビルトインを使用しています。実装をマスターする必要はありません。実装を再利用するだけです。CLIs。I don’t want to master them、 that’s their bailiwick.私はそれらをマスターしたくありません。パフォーマンス・デルタは、アプリケーションの予想される(人的)ユース・ケースを考慮して、数秒以上の場合のみ重要になります。

スクリプトの残りの部分では、主に、純粋に実装されているbashシェル・ビルトインを利用します。C BASH開発者。

すべてが社内で行われ、完全にマイクロ最適化され、デフォルトの検索オプションでこのスクリプトを破ることができず、キャッシュシステムを使用できない反対のタックを見るには、ここでは良い例ですhttps://github.com/BurntSushi/ripgrep

最初の#performance #benchmarkをそのページからプルし、おもちゃのサンプル・ツリー・サイズ(linuxカーネル・ソース)から異機種ツリーにスケール・アップするだけです。23GB: (3回の反復後に最適に実行されます。言語=en_US.UTF-8)

    % du -sh .
    23G .
    % time rg -uuniw '[A-Z]+_SUSPEND' | wc -l
    6259
    rg -uuniw '[A-Z]+_SUSPEND' 9.46s user 16.08s system 261% cpu 9.759 total
    wc -l 0.00s user 0.07s system 0% cpu 9.759 total
    % time pffxg.sh -- -wnE '[A-Z]+_SUSPEND' | wc -l
    5855
    pffxg.sh -- -wnE '[A-Z]+_SUSPEND' 16.66s user 2.68s system 429% cpu 4.501 total
    wc -l 0.00s user 0.00s system 0% cpu 4.501 total

検索のためにカーネルのファイルシステムのキャッシュの状態に深く結びついているものをマイクロ最適化するのは非常に愚かです。パフォーマンスタイミングの変動は、ファイルの内容のコーパスへのアクセス速度によって支配され、最終結果に他のどの要因よりも重要度が高くなります。ONA NVMe 助けて、しかし、この空間のビートに何もRAM 自分。

そのため、大きなファイルのコーパスに対してインメモリーの圧縮キャッシュを使用すると、パフォーマンスのタイミングが安定します。誰も、それを支えるほど大切なものだと思わなかったのは驚きです。

2番目の#performance #benchmarkをそのページから取り出して、以前と同じようにスケール・アップします(同じ)。23GB ツリー:

    % time rg -tc -uuuiwn '[A-Z]+_SUSPEND' | wc -l
    5629
    rg -tc -uuuiwn '[A-Z]+_SUSPEND' 3.51s user 1.71s system 1141% cpu 0.457 total
    wc -l 0.00s user 0.05s system 11% cpu 0.457 total
    % time LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE '[A-Z]+_SUSPEND' | wc -l
    5628
    LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE  3.14s user 0.88s system 1055% cpu 0.381 total
    wc -l 0.00s user 0.00s system 0% cpu 0.381 total

チューニング済pffxg.sh このためにripgrepをマイクロ最適化するすべての作業にもかかわらず、まだ高速ですC-file検索。

このスクリプトの使用方法AOSP スケジュールA レポ 同期とそれ以降pffxg.sh **lz4-compressed-cacheシードから-tmpfs**仕事の前に毎朝走るコロンタブ) PFFXG_CACHE=... 設定~/.pffxg.conf ファイル。したがって、pffxg.sh 稼働日中に実行した呼出しでは、tmpfsカーネルのファイルシステムのキャッシュの状態がどのようなものであったとしても。

.25M次の間のLOC ripgrep およびugrep. 632 LOCのためのpffxg.sh。バカ

そんな小さなプログラムなので、pffxg.sh ほぼゼロの努力で内部に強力なフックを与えることができます。でもgrep コマンド自体はカスタマイズ可能です。引数の末尾に追加されたファイル名のリストを受け入れることができるファイルの選択コーパスで実行する必要があるコマンドは、フェアゲームです。こちら”合計行数MiLOC“ linuxカーネルgit repoでの演習:

    % time find *-type f | xargs wc -l | awk '{ $2 == "total" {a+=$1} END {print a/1024**2}'
    28.451
    find *-type f 0.00s user 0.06s system 2% cpu 2.733 total
    xargs wc -l 0.53s user 1.02s system 54% cpu 2.853 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.23s user 0.59s system 28% cpu 2.853 total

% time pffxg.sh --workers 8 --cmd wc --all -- -l | awk '{$2 == "total" {a+=$1} END {print a/1024**2}'
    28.4506
    pffxg.sh --workers 8 --cmd wc --all -- -l 0.92s user 0.66s system 826% cpu 0.192 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 11% cpu 0.192 total

ripgrep バージョン:

    % time rg -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    28.4284
    rg -c \$ 2.12s user 2.19s system 276% cpu 1.564 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.58s user 0.45s system 66% cpu 1.564 total

制限は次のとおりですC-files (同じlinuxツリー):

    % time pffxg.sh --workers 8 --cc --cmd wc -- -l | awk '$2 == "total" {a+=$1} END {print a/1024**2}'
    25.3935
    pffxg.sh --workers 8 --cc --cmd wc -- -l 0.76s user 0.54s system 734% cpu 0.177 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 9% cpu 0.177 total

およびripgrep バージョン:

    % time rg -tc -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    25.3844
    rg -tc -c \$ 3.49s user 1.54s system 441% cpu 1.140 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.38s user 0.38s system 66% cpu 1.140 total

実際のアプリケーション・パフォーマンスは、バランス、柔軟性、機能的なプログラミング手法から来ています。これは、バランスと柔軟性の観点から作業するうえで役立つ、静的コンパイル済プログラミング言語における必須のマイクロ最適化戦術の修正によるものではありません。このような過剰な必須言語は、非常に特定の問題ドメインにとって大きなターゲットですが、システム全体のアプリケーション・パフォーマンスにとっては恐ろしいものです。

pffxg.sh これは製品ではなく、販売ピッチではありません。■■■■■■■■■■■■■■■■■■■■GitHubのfiltered-recursive-grepソリューションの長い歴史に精通している場合は、すべてAndy Lesterのオリジナルの問題という概念を前提としていますPerl 導入吐くで書かれたということでした。Perl。パフォーマンスの観点から唯一の本当の問題は、Perl Andyによって書かれました。Andyは、システムのパフォーマンスの概念(農業など)にノックがないようです。見つける 専用のパラレル化作業C バイナリ)。しかし、代わりに、シングルスレッドピュアとしてコード全体をキャプチャしようとすることで、遅延した移植性を目指しましたPerl 奇数。

千本の花が咲くなんて、どんなにバカに見えても。