perf

速度を上げるためにコードを変更する前に、測定してください。測定のない速度に関する主張は、単なる推測です。推測に基づく変更は、コードを遅くする可能性があります。

高速パス：ユーザーが測定済みの数値が正しいかどうかだけを尋ねている場合は、コードを変更しません。verify スキルを読み、measurement.md に従って数値を確認してください。ユーザーがコードが遅い理由だけを尋ねている場合や、プロファイルまたはトレースファイルを提示している場合も、コードは変更しません。ステップ 4 に進み、該当する資料の指示どおりに報告してください。

1. 何かを測定する前に、以下のステップを項目とするタスクリストを作成してください。すでにタスクリストがある場合は、これらのステップを追加してください。ステップをスキップする場合は、完了としてマークし、テキストに skip: <reason> を追加してください。前のステップに戻る場合は、そのステップとそれ以降の各ステップを新しい項目として追加してください。
2. 目標を一文で示してください。対象の操作、入力、成功とみなす数値を含めます。目標はユーザーまたは仕様から取得してください。誰からも提示されていない場合は、現実的な入力でばらつきを超える改善を目標とし、その旨を伝えてください。
3. 再実行できる測定方法を用意してください。スクリプトまたはコマンドと、現実的な入力を用意します。それぞれを 5 回以上実行してください。測定を信頼する前に、measurement.md に従って確認してください。ステップ 4 では、その最初の確認に回答します。ベースラインとして、数値、単位、実行回数、ばらつきを記録してください。
4. 観察に基づいて、数値の改善を妨げている単一のリソース、つまりボトルネックを特定してください。ソースコードから推測してはいけません。プロファイラー、トレース、またはカウンターを使用してください。プロファイラーは処理を遅くするため、プロファイル実行から得た数値は決して報告しないでください。実行中のプロセスについては、live-process.md に従ってください。既存のプロファイル、トレース、ダンプ、またはログファイルについては、capture-file.md に従ってください。
5. ボトルネックに対して、一度に 1 つの変更を行い、最も低コストな変更から試してください。まず、結果を使う箇所がない処理を取り除きます。次に、処理を一度だけ実行して結果を保持します。その次に、処理量を減らします。次に、処理を後回しにします。その次に、誰も待たないタイミングで処理します。それから、並列実行します。処理そのものを安くするのは最後の手段です。結果を保持する変更、処理を遅らせる変更、または処理を並列実行する変更は、動作を変える可能性があります。その場合は、implement の指示どおり、まず失敗するテストを追加してください。
6. 同じセットアップで再測定し、新旧のバージョンを交互の順序で実行してください。変更した経路を対象とするテストを実行します。テストに合格し、改善がばらつきを超えた場合にのみ、変更を残してください。そうでなければ、元に戻してください。変更を残し、その変更が目標を達成したら、ステップ 7 に進みます。達成していない場合は、ステップ 4 に戻ります。
7. 改善を報告する前に、verify スキルを読み、テスト、ビルド、リンターについてその指示に従ってください。verify が定義するデモとして、測定スクリプトを使用してください。改善は、検証済みの基準ではなく、測定値として報告してください。
8. 結果を報告してください。変更前後の数値を、それぞれ単位、実行回数、ばらつき、ボトルネックとともに示します。変更内容と、測定に使用した入力も明記してください。

ルール：

• ベースラインを取得する前に、速度向上を目的としてコードを変更してはいけません。
• 2 回の測定の間に行う変更は 1 つだけにし、各改善の原因を特定できるようにしてください。
• 診断の依頼には、修正ではなく診断を返してください。各所見の根拠を示してください。
• デッドロック、クラッシュ、誤った結果は不具合であり、速度低下ではありません。修正は debug に回してください。
• 測定でボトルネックと示されていないコードを最適化してはいけません。
• ばらつきを超える改善が 3 回連続で得られなかったら停止してください。測定結果とボトルネックを報告し、判断はユーザーに委ねてください。
• セッション後も作業を続ける場合は、implement の「てこを作る」原則に従い、測定スクリプトを diff に残してください。
• 数値を捏造してはいけません。失敗した測定は、失敗したと報告してください。
• 読む必要がある生のペイロードが約 2,000 行を超える場合は、サブエージェントに渡してください。research の「コンテキストウィンドウを守る」原則に従い、セッションには要約した所見だけを残してください。