アプリケーション・パフォーマンス
Joe Schaefer多くの開発者は、パフォーマンスの最適化を考える罠に陥るのは、コードの各行をできるだけ効率的にすることです。、または彼らが見つけることができる最速のプログラミング言語でアプリ全体を書き込むことを選択。
▲’実は反対です。アプリケーションのアーキテクチャ上の制約から始めて、それらを使用して監視対象にドリルダウンします。”遅い” プログラムの一部。その部分’s 実装は、実行する必要がある他のすべてのパフォーマンス選択をガイドします。すべて’その部品ほど低速ではないので、これ以上最適化する必要はありません。代わりに、人間の表現と実装のシンプルさと明確さ、専門家以外の読者に焦点を当てるSSDLC ソフトウェア、プログラムの残りの部分’コード
あなたはこのプレイブックで反復することができますが、私は’僕のキャリアで3つのイテレーションを超える必要はなかった。
そのため、次のようなエレガントなプログラミング言語を使用してください。Python3 または写本/タイプスクリプトそして、オープンソースの世界で主題の専門家(SME)があなたに力を与えますC/C++ 特別な目的のためのネイティブ結合。ビジネス・ロジックに対して行うことは、任意の動的プログラミング言語がすぐに使用できる**よりも高速である必要はありません。
依存関係のないバッシュ・スクリプトでも、多くの基本的なタスクを実行できるソリューションです。こちら’『Augmented Reality Firm』マジックリープ 数年前、不器用さを取り替えるOpenGrok マルチプロセッサの並列化を利用するサービスxargs -Pおよびサポートコンピュータサイエンス 簡単な検索エマックス/ヴィム バインディング
https://github.com/joesuf4/home/blob/wsl/bin/pffxg.sh
このスクリプトは、静的なコンパイル済プログラミング言語で記述されたGitHubの通常の疑わしいスクリプトよりも高速です。ただし、ボトルネックの正確な特定謀殺する (大量のループ) フォーク+エクセク 真ん中の呼び出し、および使用xargs 代わりに、10行に実装されたコア・アルゴリズムを使用して、このスクリプトとよく似たスクリプトを取得します。シェル.
▲’SMEのオープン・ソース・コミュニティも使用しています’賢い方法で、代わりに”フィルタされた再帰的grep” GitHubに対する実装が実行されました。自分の(スレッド化された)実装を内部的に採用して維持する代わりに、見つける, xargsおよびgrepプリインストールされている実行可能ファイルを再利用するだけSME‘sは何十年もの間、現状のまま完成しており、主にシェルbuiltinsを残りの部分に使用しています。IDON’実装をマスターする必要があり、その実装を再利用するだけです。CLIs。IDON’それをマスターしたい、、、’Bailiwick(バイリウィック) アプリケーションのパフォーマンス・デルタは、数秒以上の場合のみ重要’想定される(人間的な)ユースケース。
スクリプトの残りの部分では、主に、純粋に実装されているbashシェル・ビルトインを利用します。C.
すべてが社内で行われ、完全にマイクロ最適化され、それでもできる逆のタックを見るため’デフォルトの検索オプションでこのスクリプトを打ち負かし、キャッシュシステムを使用できません。ここでは良い例ですhttps://github.com/BurntSushi/ripgrep
最初の#performance #benchmarkをそのページからプルし、おもちゃのサンプル・ツリー・サイズ(linuxカーネル・ソース)から異機種ツリーにスケール・アップするだけです。’s 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 コマンド自体はカスタマイズ可能です。引数の末尾に追加されたファイル名のリストを受け入れることができるファイルの選択コーパスで実行する必要があるコマンドは、フェアゲームです。こちら’A “合計行数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 アンディが書いたのは、’tは、システムのパフォーマンスの概念(農業など)にノックがあるようです見つける 専用のパラレル化作業C バイナリ)。しかし、代わりに、シングルスレッドピュアとしてコード全体をキャプチャしようとすることで、遅延した移植性を目指しましたPerl 奇数。
千本の花が咲くなんて、どんなにバカに見えても。