memory-benchmark

メモリのベンチマークと分析

perf/memory クレートは、WAL および MVCC のジャーナルモードでの SQL ワークロードのメモリ使用量をベンチマークします。グローバルアロケーターとして dhat を使い、ヒープ割り当てをすべて追跡します。また、プロセスレベルの RSS スナップショットには memory-stats を使います。

さらに、スタック使用量の調査用ヘルパーバイナリ stack-report も含まれています。 このバイナリは stacker フィーチャーを有効にして SQL ペイロードを実行し、 プロセス内で turso_stack のトレースイベントをキャプチャします。stderr の ログテキストを解析する代わりに、構造化されたトレースフィールドを集約します。

場所

• ベンチマーククレート：perf/memory/
• CodSpeed ベンチマーククレート：perf/memory/codspeed/（CI での割り当てリグレッション追跡）
• 分析スクリプト：perf/memory/analyze-dhat.py
• dhat 出力：dhat-heap.json（各実行後に CWD に書き込まれます）

このクレートはライブラリとバイナリに分かれています。ワークロードエンジンは memory_benchmark::workload にあります（run_workload、WorkloadConfig、 WorkloadObserver、JournalMode／WorkloadProfile 列挙型、および create_profile）。memory-benchmark バイナリは、その上に dhat／RSS 計測を追加した 薄い CLI です。ランダム化プロファイル（read-heavy、mixed）では固定の RNG シード（profile::WORKLOAD_RNG_SEED）を使うため、実行ごとに同一のワークロードになります。

FTS クエリの割り当て

fts-memory バイナリと perf/memory/codspeed/benches/fts_queries.rs は、 既存の SQL プロファイルランナーとは独立して memory_benchmark::fts を共有します。 コマンド、コーパスの詳細、計測上の制限については perf/memory/README.md を参照してください。

cargo run -p memory-benchmark --features fts --bin fts-memory -- \
  --query common --state warm --documents 10000 --queries 100 \
  --dhat-file /tmp/fts-warm.json > /tmp/fts-warm-report.json
python3 perf/memory/analyze-dhat.py /tmp/fts-warm.json --modules --top 20
cargo test -p memory-benchmark-codspeed --features fts --bench fts_queries -- --test

デバッグ実行は正しさの確認にのみ使い、最適化された dhat 調査には、デバッグ情報があり LTO を使わない --profile bench-profile を使ってください。クエリケースは rare、 common、and、or、phrase、ranked です。状態 first ではクエリが 1 回必要です （デフォルト）。warm では、1 回の計測対象外のウォームアップ後、1 つの永続接続で デフォルト 100 クエリを実行します。デフォルトのコーパスには 10000 件のドキュメントが 含まれます。ローカルでの比較には 1000 件と 100000 件が便利です。WAL と 1 接続が デフォルトのままです。

トランザクションの全ライフサイクルを計測するには、--mode mvcc --connections 2 --transactions-per-connection 10 --queries-per-transaction 2 を指定します。これにより、 BEGIN CONCURRENT と COMMIT を含む 20 件のトランザクションと 40 件のクエリを計測します。 WAL では BEGIN を使います。明示的なトランザクション数は --queries と併用できません。 それ以外の場合、クエリ数は接続ごとの数です。クエリワーカーの開始前にすべての トランザクションを開始し、コミット前にすべてのワーカーを終了します。接続はラウンド間で 維持されます。1 接続ではトランザクションを繰り返し、2／4 接続では重複するスナップショットを 扱います。明示的なトランザクションを選択した場合、ウォームアップでは接続ごとにクエリを 1 回実行する完全なトランザクションを 1 件実行します。レポートには、完了した トランザクション数／クエリ数と max_active_transactions が含まれます。ヒープの合計は、 すべての接続とスケジューリングを集計したものです。

FtsWorkload は FtsObserver を通じて setup、open、warmup、run、 cleanup、done を出力します。CLI の DhatObserver は run でプロファイリングを 開始し、接続が破棄される前の cleanup で停止します。各遷移では stderr に JSON の フェーズイベントが出力され、最終レポートの phases 配列にも保存されます。stderr には dhat の診断情報も含まれます。フェーズイベントは jq -Rc 'fromjson? | select(.event == "phase")' で絞り込めます。 経過時間イベントにはプロファイラーのオーバーヘッドが含まれます。成功したかどうかは終了 ステータスを確認してください。after_batch は、接続ごとのクエリ実行後、または 1 回の トランザクションラウンドですべてのコミットが完了した後に、ライブヒープをサンプリングします。 ワーカーのエラーは、ロールバックとクリーンアップの前に結合されます。

セットアップ、データベースのオープン、ウォームアップ、クリーンアップは計測対象外です。 ヒープの合計、ピーク、保持バイト数、クエリごとのライブバイトサンプルは、プロファイリング前に 割り当てられたキャッシュではなく、クエリフェーズの割り当てを追跡します。プロファイリング後の RSS には、dhat 自身のスタック／レポートのオーバーヘッドが含まれます。JSON は stdout に、 割り当てスタックは --dhat-file に出力されます。 Divan ターゲットでは、dhat のアロケーターを使わず、ワークスペースの CodSpeed 互換 Divan 依存関係を使用し、fts-queries メモリ CI シャードで実行します。cargo codspeed build -m memory -p memory-benchmark-codspeed --features codspeed,fts でビルドし、cargo codspeed run -m memory -p memory-benchmark-codspeed --bench fts_queries で実行します。 各クエリには、1000 件および 10000 件のドキュメントでの初回／ウォーム版と、10000 件のドキュメントでの追加の 10／100 クエリのウォーム版があります。名前は (state, documents, queries) を表します。 追加の 24 個の transactions ケースでは、1000 件のドキュメント、接続あたり 10 トランザクション、トランザクションあたり 2 クエリを使用します。6 つすべてのクエリケースについて、WAL／接続 1 個と、MVCC／接続 1、2、または 4 個を実行します。名前は (mode, connections, transactions_per_connection, queries_per_transaction) を表します。Divan は、何もしないオブザーバーを使用して、同じ FtsWorkload::prepare メソッドと run メソッドを使います。 Divan／CodSpeed ターゲットでは、接続数にかかわらず Tokio の current-thread ランタイムを使用します。トランザクションは並行して実行されますが、クエリタスクは 1 つのスレッドで実行されます。dhat CLI では、並列クエリの測定にマルチスレッドランタイムを引き続き使用します。 codspeed 機能を使わずにローカルでビルドする場合は、システムアロケーターに Divan の AllocProfiler を設定します。ローカルでの割り当て出力を得るには、cargo bench --profile bench-profile -p memory-benchmark-codspeed --features fts --bench fts_queries -- transactions --sample-count 3 --sample-size 1 を実行します。すべてのクエリタスクは、Divan が測定するスレッドで実行されます。 プロセス全体の並列実行時の合計値とピーク値には、dhat CLI を使用してください。alloc は割り当て呼び出しをカウントします。realloc による増加は grow として別に記録されます。max alloc は、クエリごとではなく、測定対象シーケンス全体のピーク時の生存メモリです。 既存の Criterion メモリプロファイルと、セットアップを含むそのメトリクスに変更はありません。

キャッシュ容量を超える調査では、上記のトランザクションフラグとともに --documents 20000 --extra-tokens 1024 --cache-pages 200 --min-index-bytes 268435456 を使用します。 追加トークンには固定シードを使い、クエリの一致結果は変わりません。最小値は、コーパスやデータベースのサイズではなく、格納された FTS チャンクのバイト数に対して確認されます。セットアップではコアのテストヘルパーのバッキング行リーダーを使い、その後、調査用の接続を閉じます。 JSON の index には segment_bytes、segments、largest_segment_bytes、page_size、configured_cache_pages が記録されます。corpus には 3 つのオプションが記録されます。event: "index" の stderr レコードは、測定または却下の前にサイズを報告します。 キャッシュページ数は 200 以上にする必要があります。省略した場合はエンジンのデフォルト値が使われます。追加トークン数と最小値をゼロにすると、小さなコーパスが維持されます。256 MiB のインデックスは、現在の 192 MiB の保持セグメント予算を超えますが、キャッシュされたサーチャーがセグメントデータを保持する場合があり、稼働中のカーソルは表示中のすべてのセグメントを読み込みます。これはキャッシュの退避やメモリ上限の証明にはなりません。読み取り専用トランザクションでは、スナップショットが変化する際の 4 サーチャー上限を検証できません。ライターアリーナ（64 MiB）とドキュメントフラッシュ（1000）の上限はセットアップ中に適用され、クエリのプロファイリング対象外です。すべての注意事項については README を参照してください。 対応する Divan ケースはオプトインです。--features fts-stress --bench fts_queries -- oversized_index を指定すると、MVCC 接続 1 個または 2 個、3 トランザクション、トランザクションあたり 2 クエリ、サンプル 1 回で実行されます。CI では codspeed,fts を指定してビルドし、大きなケースはコンパイル時に除外したうえで、fts-queries の小さなケースを実行します。 CodSpeed では、大きなケースの実行に構成ごとに約 18 分かかりました。位置フィルターでは Divan のケースを分離できませんでした。キャッシュ容量を超える実行には、ローカルの Divan または dhat を使用してください。 ビルドジョブでは cargo test -p memory-benchmark --features fts --locked も実行します。

スタックレポートの実行

SQL の変換／実行プローブからスタック使用量を調査する場合に使用します。サーバーログや CI のスタックサイズ出力と比較するときは、--features stacker を指定してリリースモードでスタックレポートを実行してください。デバッグビルドではスタック差分が実際より大幅に大きくなることがあるため、手早くローカルで反復する場合にのみ使用してください。

cargo run --release -q -p memory-benchmark --features stacker --bin stack-report -- \
  --sql path/to/payload.sql \
  --top 40

便利なオプション：

--sql FILE|-             # SQL payload, or stdin with -
--format human|json|csv  # output format
--top N                  # aggregate/span rows per statement in human output
--statement N[,N...]     # only include reports for 1-based statement indexes
--sql-contains TEXT      # only include reports for statements containing TEXT, ASCII case-insensitive

レポートはステートメント単位で作成されます。各 SQL ステートメントについて、実行前に残っているスタック量、そのステートメントの実行中にサンプリングされた残りスタック量の最小値、および stack_used = baseline_remaining_stack - min_remaining_stack を記録します。ステートメントは stack_used の降順で並べ替えられるため、スタックを最も多く使用した SQL ステートメントが先頭になります。人間向けレポートには、total_inclusive_stack_used の降順で並べ替えた、全体およびステートメントごとのスパン集計も出力されます。これらの集計行は label と detail の組み合わせでグループ化され、呼び出し回数、自己スタックの合計／最大値、包括スタックの合計／最大値、スパン開始時点での累積スタックの最大値、およびステートメントの残りスタック量が最小になった時点でアクティブだったスパンの peak_path_hits を含みます。

各ステートメント内では、元のトレース出力順序を trace_sequence フィールド（人間向け出力では seq）に保持したまま、生のスパン行も stack_used の降順で並べ替えられます。生のスパン行には inclusive_stack_used が含まれます。これは、そのスパンがアクティブな間にサンプリングされた最も深い残りスタック量までの、スパンの親スタックレベルからの使用量です。これは包括的なプロファイラー形式の指標であり、ネストしたスパンは意図的に重複します。ステートメント全体のスタック使用量を合計するのではなく、寄与している可能性の高い項目を順位付けするために使用してください。

JSON および CSV 形式は決定的で、実行結果の比較を目的としています。CSV では row_type 列を使用し、global_aggregate、statement_aggregate、span、statement の各行を示します。

ステートメントフィルターはレポートにのみ影響します。ランナーは SQL ペイロード全体を順番に実行するため、スキーマ／データのセットアップや、それ以前のステートメントは、後から選択されたステートメントでも引き続き利用できます。複数の --statement フィルターと --sql-contains フィルターを指定できます。両方を指定した場合、ステートメントは両方の種類の条件に一致する必要があります。

stack-report は turso_parser::parser::Parser::next_cmd() でペイロードを分割します。その後、結果列のないステートメントは実行し、行を返すステートメントはクエリを実行して結果を最後まで読み取ります。スタックレポートのバインディングにおける execute_batch のセマンティクスは変更しないでください。

ランナーは現在、固定のインメモリデータベースを使用し、生成列、カスタム型、マテリアライズドビューを内部で有効にしています。データベースパスの選択や、これらの実験的機能の切り替えを行うスタックレポート用 CLI フラグはありません。

ベンチマークの実行

必ずリリースモードで実行してください。デバッグビルドではメモリー割り当てのパターンが大きく異なるため、実際の使用状況を反映した結果になりません。

# Basic: single connection, WAL mode, insert-heavy workload
cargo run --release -p memory-benchmark -- --mode wal --workload insert-heavy -i 100 -b 100

# MVCC with concurrent connections
cargo run --release -p memory-benchmark -- --mode mvcc --workload mixed -i 100 -b 100 --connections 4

# Run a final checkpoint after the workload
cargo run --release -p memory-benchmark -- --mode wal --workload read-heavy --checkpoint

# Exercise recursive queues at a 10k-row target cardinality
cargo run --release -p memory-benchmark -- --mode wal --workload recursive-cte -i 20 -b 10000

# Guarantee automatic MVCC checkpoints during the run by lowering the
# logical-log threshold (default is ~4 MB, more than small workloads write)
cargo run --release -p memory-benchmark -- --mode mvcc --workload insert-heavy --mvcc-checkpoint-threshold 16384

# All CLI options
cargo run --release -p memory-benchmark -- \
  --mode wal|mvcc \
  --workload insert-heavy|read-heavy|mixed|scan-heavy|recursive-cte|series-blob|update-churn \
  -i <iterations> \
  -b <batch-size> \
  --connections <N> \
  --checkpoint \
  --timeout <ms> \
  --cache-size <pages> \
  --mvcc-checkpoint-threshold <bytes>   # MVCC only; -1 disables auto-checkpoint
  --mvcc-gc-threshold <versions>        # MVCC only; -1 disables inline GC
  --format human|json|csv

2 つの --mvcc-*-threshold フラグは、実行前に共有の mv_store に対応する PRAGMA を設定します。これらは MVCC GC の動作を切り分けるための調整項目です。チェックポイントを無効にし（--mvcc-checkpoint-threshold=-1）、インライン GC のみが再利用を行うようにしたうえで、update-churn ワークロードで GC しきい値を A/B 比較します（例：-1 は無効、16384 はデフォルト、またはより小さい、より積極的な値）。

実行ごとに、カレントディレクトリに dhat-heap.json が生成されます。このファイルには、実行全体について、割り当て箇所ごとのデータが含まれます。

組み込みワークロードプロファイル

プロファイル	説明	セットアップ
insert-heavy	100% INSERT 文	テーブルを作成
read-heavy	90% は ID による SELECT ／ 10% は INSERT	10k 行をシード
mixed	50% は SELECT ／ 50% は INSERT	10k 行をシード
scan-heavy	LIKE を使った全テーブルスキャン	10k 行をシード
recursive-cte	線形、優先度付きキュー、UNION-distinct、外側の LIMIT を使った再帰 CTE クエリを繰り返し実行	スキーマのセットアップは不要です。batch-size は再帰結果の目標カーディナリティです
series-blob	INSERT INTO bench(data) SELECT zeroblob(2048) FROM generate_series(1, ?)	bench を作成します。batch-size はシリーズの長さです
update-churn	固定された 10k 行セットに対して UPDATE を繰り返し実行します（書き込み同士の競合を避けるため、キー空間は接続ごとに分割されます）	10k 行をシードします。置き換えられたバージョンを生成します。これは MVCC GC の蓄積ケースです。

プロファイルは perf/memory/src/profile/ にある Profile トレイトを実装します。新しいワークロードを追加するには、トレイトを実装する新しいファイルを作成し、main.rs の WorkloadProfile enum に組み込みます。

出力の理解

ベンチマークでは、次の 3 種類のメトリクスが報告されます。

RSS（プロセスレベル）

memory-stats クレートを使って測定します。ヒープ、mmap されたファイル（WAL、OS ページキャッシュに取り込まれた DB ページ）、tokio ランタイムなど、すべてが含まれます。スナップショットはフェーズの切り替え時（セットアップ -> 実行）と各バッチの後に取得されます。

• ベースライン：DB の処理を行う前の RSS（ランタイムのオーバーヘッド）
• ピーク：実行中に観測された最大 RSS
• 正味の増加：最終 RSS からベースラインを引いた値。ワークロードに起因するメモリ量です

ヒープ（dhat）

dhat グローバルアロケーターを使った精密な割り当て追跡です。明示的なヒープ割り当て（malloc/alloc）のみをカウントし、mmap は対象外です。

• 現在：測定時点でまだ割り当てられているバイト数
• ピーク：実行全体を通して同時に存続した割り当ての最大量
• 割り当て総数：個々の割り当て呼び出し数
• 総バイト数：累積割り当てバイト数（解放済みメモリを含む）。割り当て圧力を測定します

ディスク

ベンチマーク完了後のファイルサイズです。

• DB ファイル：.db ファイル
• WAL ファイル：.db-wal ファイル（WAL モードのみ）
• ログファイル：.db-log ファイル（MVCC 論理ログのみ）

dhat 出力の分析

ベンチマークを実行した後、分析スクリプトを使って dhat-heap.json から読みやすいレポートを生成します。

# Overview: top allocation sites by bytes live at global peak
python3 perf/memory/analyze-dhat.py dhat-heap.json --top 15 --modules

# Focus on a specific subsystem
python3 perf/memory/analyze-dhat.py dhat-heap.json --filter mvcc --stacks
python3 perf/memory/analyze-dhat.py dhat-heap.json --filter btree --stacks
python3 perf/memory/analyze-dhat.py dhat-heap.json --filter page_cache --stacks

# Sort by different metrics
python3 perf/memory/analyze-dhat.py dhat-heap.json --sort-by eb  # bytes at exit (leaks)
python3 perf/memory/analyze-dhat.py dhat-heap.json --sort-by tb  # total bytes (pressure)
python3 perf/memory/analyze-dhat.py dhat-heap.json --sort-by mb  # max live bytes per site

# JSON output for programmatic use
python3 perf/memory/analyze-dhat.py dhat-heap.json --json

ソートメトリクス

フラグ	メトリクス	使用場面
gb	グローバルピーク時の存続バイト数（デフォルト）	メモリ使用量が最大となった時点で、何が大部分を占めているかを調べる場合
eb	終了時の存続バイト数	メモリリークや解放されずに残っているものを調べる場合
tb	割り当て総バイト数	割り当て圧力の高い箇所（GC churn）を特定する場合
mb	サイトごとの最大存続バイト数	サイトごとのメモリ使用量の最大値を調べる場合
tbk	割り当て総数	頻繁に割り当てを行うアロケーター（小さな割り当てが多数あるもの）を特定する場合

分析フラグ

• --top N — 上位 N サイトを表示します（デフォルトは 15）
• --filter PATTERN — 部分文字列を含むサイト／スタックに絞り込みます（例：mvcc、btree、wal、pager）
• --stacks — 上位の割り当てサイトについて、完全なコールスタックを表示します
• --modules — 高レベルの内訳を確認できるよう、クレート／モジュールごとに集計します
• --json — 機械可読な集計結果を出力します

一般的なワークフロー

メモリ使用量や回帰の疑いを調査する場合：

1. ベンチマークを実行する — シナリオに合ったパラメーターを指定します：

   cargo run -p memory-benchmark -- --mode mvcc --workload mixed -i 500 -b 100 --connections 4
   

2. 大まかな全体像を把握する — どのモジュールが最も多くのメモリを使っているかを確認します：

   python3 perf/memory/analyze-dhat.py dhat-heap.json --modules --top 20
   

3. 負荷の高いモジュールを詳しく調べる — たとえば turso_core が大部分を占めている場合：

   python3 perf/memory/analyze-dhat.py dhat-heap.json --filter turso_core --stacks --top 10
   

4. リークを確認する — 終了時にも存続しているが、本来は残るべきでないものがないかを確認します：

   python3 perf/memory/analyze-dhat.py dhat-heap.json --sort-by eb --top 10
   

5. モードを比較する — WAL と MVCC で同じワークロードを実行し、レポートを比較して MVCC のバージョニングによるメモリコストを確認します。

並行処理の詳細

--connections > 1 の場合：

• セットアップフェーズ（スキーマ作成、データ投入）は、常に単一の接続で順次実行されます
• 実行フェーズでは、接続ごとに1つの tokio タスクを起動し、それぞれのバッチを並行して実行します
• --checkpoint を指定すると、実行フェーズ後に単一接続で PRAGMA wal_checkpoint(TRUNCATE) を実行する最終フェーズが追加されます
• 各接続には busy_timeout が設定されます（デフォルトは30s、--timeout で変更可能です）
• WAL モードでは BEGIN、MVCC では BEGIN CONCURRENT を使用します
• Profile トレイトの next_batch(connections) は、重複しない行 ID を持つバッチを接続ごとに1つ返します

CI での CodSpeed による割り当て追跡

.github/workflows/codspeed-memory.yml は、CodSpeed のメモリ計測機能（eBPF ベースの malloc 追跡：ピークメモリ、総割り当て量、割り当て回数）を使って、すべてのワークロードプロファイルを両方のジャーナルモードで実行し、割り当てのリグレッションが PR で検出されるようにします。ベンチハーネスは別クレートの perf/memory/codspeed/ です（criterion ベンチマークの名前は <mode>/<workload>/<total-ops>。例：mvcc/insert-heavy/2000。CLI のデフォルトよりもイテレーション回数を大幅に少なくしています）。各（モード、ワークロード）の組み合わせは1x／2x／4xのスケールで実行されます。バッチサイズは同じまま、イテレーション回数を増やすため、サイズを比較するとワークロード量に応じたメモリの増加を確認できます。さらに、8x の <ops>-checkpoint バリアントでは、計測にチェックポイント処理が含まれることを保証します。mvcc_checkpoint_threshold を16 KiBに下げて、実行中に MVCC の自動チェックポイントが発生するようにし（WAL の1000フレームのしきい値は core/storage/wal.rs にハードコードされています）、最後に明示的な PRAGMA wal_checkpoint(TRUNCATE) を実行します。このワークフローはベンチバイナリを一度ビルドした後、ワークロードプロファイルごとに CI ジョブを1つずつ並列実行し、それぞれが名前でベンチマークをフィルタリングします。これは CodSpeed の sharded-benchmarks ドキュメントに記載されたシャーディングパターンです。

ベンチクレートには [[bin]] ターゲットを含めないでください。cargo はパッケージのバイナリ（release プロファイルでは panic=abort）をベンチ（panic=unwind）と並行してビルドします。その結果、重複する turso_sdk_kit cdylib/staticlib のビルド単位がハッシュなしの出力ファイル名で衝突し、ビルドが失敗します。そのため、ベンチは perf/memory 自体には配置されていません。

ローカルでの実行：

# Quick correctness pass (runs each benchmark once)
cargo bench -p memory-benchmark-codspeed --bench memory_profiles -- --test

# What CI runs (requires cargo-codspeed; uninstrumented outside the CodSpeed runner)
cargo codspeed build -m memory -p memory-benchmark-codspeed --features codspeed
cargo codspeed run -m memory -p memory-benchmark-codspeed --bench memory_profiles "insert-heavy"

完全な criterion サンプリングを実行したい場合を除き、-- --test を付けずに cargo bench -p memory-benchmark-codspeed を実行しないでください。各サンプルでワークロード全体が実行されます。

新しいプロファイルの追加

1. Profile トレイトを実装する perf/memory/src/profile/your_profile.rs を作成します
2. perf/memory/src/profile/mod.rs に pub mod your_profile; を追加します
3. src/workload.rs の WorkloadProfile enum にバリアントを追加します
4. src/workload.rs の create_profile() に組み込みます
5. perf/memory/codspeed/benches/memory_profiles.rs の WORKLOADS（および base_workload_size）と、.github/workflows/codspeed-memory.yml の workload マトリックスに追加し、CI で追跡されるようにします

Profile トレイト：

pub trait Profile {
    fn name(&self) -> &str;
    fn next_batch(&mut self, connections: usize) -> (Phase, Vec<Vec<WorkItem>>);
}

スキーマ作成／データ投入には Phase::Setup（単一バッチ）、計測対象の処理には Phase::Run（接続ごとに1つのバッチ）、完了時には Phase::Done を返します。

このスキルを最新の状態に保つ

このスキルドキュメントは、エージェントがメモリベンチマークツールをどのように使用するかを定める基準です。perf/memory クレートを変更する場合（プロファイルの追加、CLI フラグの変更、出力形式の変更、分析スクリプトの更新、Profile トレイトの変更など）は、この SKILL.md も更新して内容を一致させてください。具体的には：

• 新しい CLI フラグ： 「ベンチマークの実行」セクションに追加します
• 新しいプロファイル： 「組み込みワークロードプロファイル」テーブルに追加します
• 出力メトリクスの変更： 「出力の理解」セクションを更新します
• analyze-dhat.py の新しいフラグやソート用メトリクス：「dhat 出力の分析」セクションを更新します
• Profile トレイトのシグネチャ変更：「新しいプロファイルの追加」を更新します

今後のエージェントは、このドキュメントが正確であることを前提に作業します。古い手順は作業の無駄につながります。