.NET Performance Patterns

C#/.NET コードのパフォーマンス アンチパターンをスキャンし、優先順位付けされた検出結果と具体的な修正案を提供します。パターンは公式 .NET パフォーマンス ブログ シリーズを出典としており、顧客がアクション可能なガイダンスに精製されています。

使用時期

• C#/.NET コードをパフォーマンス最適化の機会について確認する
• 割り当て集約的またはいアフィシェント パターンのホットパスを監査する
• リリース前にコードベースを既知のアンチパターンについて体系的にスキャンする
• 手動パフォーマンス レビュー後の第二意見の分析

使用しない時期

• アルゴリズム複雑性の分析 — このスキルはアルゴリズム設計ではなく API 使用パターンをターゲットにしています
• ホットパスにない パフォーマンス要件がないコード — 時期尚早な最適化は避けてください

入力

入力	必須	説明
ソースコード	はい	スキャンする C# ファイル、コードブロック、またはリポジトリ パス
ホットパス コンテキスト	推奨	パフォーマンスが重要なコード パス
ターゲット フレームワーク	推奨	.NET バージョン (一部のパターンは .NET 8+ を必要とします)
スキャン深度	オプション	critical-only、standard (デフォルト)、または comprehensive

ワークフロー

ステップ 1: 参照ファイルをロードする (利用可能な場合)

references/critical-patterns.md と以下に列挙されたトピック固有の参照ファイルのロードを試みてください。これらは詳細な検出レシピと grep コマンドを含みます。

参照ファイルが見つからない場合 (サンドボックス環境やスキルが命令のみとして組み込まれている場合など)、ファイルロードをスキップし、ステップ 3 に直接進んでください 。ステップ 3 に列挙されているインラインスキャン レシピを使用してください。ファイルシステムで参照ファイルを検索する時間を費やさないでください — 予想される相対パスにない場合、利用不可です。

ステップ 2: コード シグナルを検出してトピック レシピを選択する

パターン カテゴリをチェックするかどうかを示すシグナルについてコードをスキャンします。参照ファイルがロードされている場合は、それらの ## Detection セクションを使用してください。そうでない場合は、ステップ 3 のインラインレシピを使用してください。

コード内のシグナル	トピック
async、await、Task、ValueTask	非同期パターン
Span<、Memory<、stackalloc、ArrayPool、string.Substring、.Replace(、.ToLower()、ループ内の +=、params	メモリと文字列
Regex、[GeneratedRegex]、Regex.Match、RegexOptions.Compiled	正規表現パターン
Dictionary<、List<、.ToList()、.Where(、.Select(、LINQ メソッド、static readonly Dictionary<	コレクションと LINQ
JsonSerializer、HttpClient、Stream、FileStream	I/O とシリアル化

シグナルに関係なく、構造的パターン (非シール クラス) を常にチェックしてください。

スキャン深度によってスコープが制御されます:

• critical-only: 重大パターンのみ (デッドロック、>10 倍のリグレッション)
• standard (デフォルト): 重大 + 検出されたトピック パターン
• comprehensive: すべてのパターン カテゴリ

ステップ 3: スキャンしてレポートする

500 行未満のファイルの場合、最初にファイル全体を読みます — 個別の grep レシピを実行するよりも速くほとんどのパターンを見つけます。grep を使用して数をカウントし、見落とすかもしれないパターンをキャッチしてください。

関連するパターン カテゴリごとに、以下の検出レシピを実行します。正確な数をレポートし、推定値ではありません。

コア スキャン レシピ (参照ファイルが利用不可の場合に実行してください):

# Strings & memory
grep -n '\.IndexOf(\"' FILE                    # Missing StringComparison
grep -n '\.Substring(' FILE                    # Substring allocations
grep -En '\.(StartsWith|EndsWith|Contains)\s*\(' FILE  # Missing StringComparison
grep -n '\.ToLower()\|\.ToUpper()' FILE        # Culture-sensitive + allocation
grep -n '\.Replace(' FILE                      # Chained Replace allocations
grep -n 'params ' FILE                         # params array allocation

# Collections & LINQ
grep -n '\.Select\|\.Where\|\.OrderBy\|\.GroupBy' FILE  # LINQ on hot path
grep -n '\.All\|\.Any' FILE                    # LINQ on string/char
grep -n 'new Dictionary<\|new List<' FILE      # Per-call allocation
grep -n 'static readonly Dictionary<' FILE     # FrozenDictionary candidate

# Regex
grep -n 'RegexOptions.Compiled' FILE           # Compiled regex budget
grep -n 'new Regex(' FILE                      # Per-call regex
grep -n 'GeneratedRegex' FILE                  # Positive: source-gen regex

# Structural
grep -n 'public class \|internal class ' FILE  # Unsealed classes
grep -n 'sealed class' FILE                    # Already sealed
grep -n ': IEquatable' FILE                    # Positive: struct equality

ルール:

• 検出されたパターン カテゴリに対してすべての関連レシピを実行してください
• スキャン実行チェックリストを発行します — 各レシピとヒット数をリストアップしてください
• 0 ヒット の結果は有効で価値があります (良い実装を確認します)
• 参照ファイルがロードされている場合は、それらの ## Detection レシピも実行してください

逆検証ルール: 欠落パターンの場合、常に両側をカウントして比率をレポートしてください (例: "185 個のクラスのうち N 個がシールされている")。比率が重大度を決定します — 0/185 は体系的、12/15 は一貫性修正です。

ステップ 3b: クロスファイル一貫性チェック

最適化されたパターンが 1 つのファイルで見つかった場合、兄弟ファイル (同じディレクトリ、同じインターフェイス、同じ基底クラス) が非最適化の同等物を使用しているかどうかをチェックしてください。最適化されたファイルを証拠として 🟡 Moderate としてフラグを立ててください。

ステップ 3c: 複合割り当てチェック

スキャン レシピを実行した後、単一行レシピが見落とすこれらの複数割り当てパターンを探してください:

1. 分岐 .Replace() チェーン: 複数の if/else ブランチ全体で .Replace() を呼び出すメソッド — 行ごとではなく、すべてのブランチ全体の総割り当てカウントをレポートしてください。
2. クロスメソッド チェーンング: パブリック メソッドが、それ自体が中間を割り当てるメソッドに委譲する場合 (例: A は B を呼び出し、B は 3 つの正規表現置換を実行し、その後 A は C を呼び出す)、総チェーン コストを 1 つの検出結果として報告してください。
3. 埋め込まれた割り当て呼び出しの複合 +=: result += $"...{Foo().ToLower()}" のような行は 2 つ以上の割り当て (補間 + ToLower + 連結) です — 行ごとではなく、複合コストをフラグ立ててください。
4. string.Format の特殊性: リソースロード形式文字列 (修正不可) をコンパイル時リテラル形式文字列 (補間で修正可能) から区別してください。アクション可能なサイトを列挙してください。

ステップ 4: 検出結果を分類して優先順位を付ける

各検出結果に重大度を割り当ててください:

重大度	基準	アクション
🔴 Critical	デッドロック、クラッシュ、セキュリティの脆弱性、>10 倍のリグレッション	修正が必須
🟡 Moderate	2-10 倍の改善機会、ホットパスのベストプラクティス	ホットパス上で修正すべき
ℹ️ Info	パターンが適用されるが、コードはホットパスにない可能性	プロファイリングが影響を示す場合は検討

優先順位付けルール:

1. ユーザーがホットパス コードを特定した場合、そのコード内のすべての検出結果をそれらの最大重大度に昇格させてください
2. ホットパス コンテキストが不明な場合、🔴 Critical 検出結果を無条件でレポートしてください ; 🟡 Moderate 検出結果をメモ付きでレポートしてください: 「このコードがホットパス上にある場合に影響を与えます」
3. パフォーマンスに敏感でないことが明らかなコードで微最適化を提案しないでください

スケールベースの重大度昇格: 同じパターンが多数のインスタンスに現れる場合、重大度を昇格させてください:

• 同じアンチパターンの 1-10 インスタンス → パターンの基本重大度でレポート
• 11-50 インスタンス → ℹ️ Info パターンを 🟡 Moderate に昇格
• 50+ インスタンス → 🟡 Moderate に昇格し優先度を上げ; コードベース全体にわたる体系的な問題としてフラグ立て

スキャン レシピからの正確なカウント (推定値やエージェント サマリーではない) を常にレポートしてください。

ステップ 5: 検出結果を生成する

検出結果をコンパクトに保ちます。 各検出結果は 1 つの短いブロック — エッセイではありません。ファイルではなく、重大度 (🔴 → 🟡 → ℹ️) でグループ化してください。

検出結果ごとのフォーマット:

#### ID. Title (N instances)
**Impact:** one-line impact statement
**Files:** file1.cs:L1, file2.cs:L2, ... (list locations, don't build tables)
**Fix:** one-line description of the change (e.g., "Add `StringComparison.Ordinal` parameter")
**Caveat:** only if non-obvious (version requirement, correctness risk)

コンパクト出力のルール:

• ❌/✅ コードブロックなし 自明な修正 (キーワード、パラメータ、または型変更の追加) — 1 行の修正説明で十分です。
• コードブロックは非自明な変換の場合のみ含めます (例: LINQ チェーンを foreach ループで置き換える、またはクロージャをホイスト)。
• インラインカンマ区切りリストとしてのファイル位置、テーブルではありません。 File.cs:L42 形式を使用してください。
• Impact 行を超える説明文はありません — 重大度アイコンが既に緊急性を伝えます。
• 同じ修正を共有する関連検出結果をマージしてください (例: すべての .ToLower() 呼び出しは 1 つの検出結果で、ファイルごとに分割されていません)。
• 肯定検出結果 をリストで、テーブルではありません。パターンごと 1 行: ✅ Pattern — evidence。

サマリー テーブルと免責事項で終了してください:

| Severity | Count | Top Issue |
|----------|-------|-----------|
| 🔴 Critical | N | ... |
| 🟡 Moderate | N | ... |
| ℹ️ Info | N | ... |

> ⚠️ **Disclaimer:** These results are generated by an AI assistant and are non-deterministic. Findings may include false positives, miss real issues, or suggest changes that are incorrect for your specific context. Always verify recommendations with benchmarks and human review before applying changes to production code.

検証

結果を提供する前に、以下を確認してください:

• すべての重大パターンがチェックされた (参照ファイルまたはインラインレシピから)
• トピック固有のレシピは一致するシグナルが検出された場合のみ実行
• 各検出結果には具体的なコード修正が含まれている
• スキャン実行チェックリストが完了している (すべてのレシピが実行された)
• サマリー テーブルが最後に含まれている

一般的な落とし穴

落とし穴	正しいアプローチ
すべての Dictionary を FrozenDictionary が必要として フラグ立て	構築後にディクショナリが変更されない場合のみフラグ立て
非同期メソッドで Span<T> を提案	非同期コードでは Memory<T> を使用; Span<T> は同期ホットパスのみ
ホットパス外の LINQ をレポート	特定されたホットパスまたはタイト ループの LINQ のみフラグ立て; LINQ は低頻度で実行されるコードで許容可能。.NET 7 以降、LINQ Min/Max/Sum/Average はベクトル化されています — LINQ の一括禁止は誤った考えです
非同期メソッドで ConfigureAwait(false) を提案	ライブラリ コードにのみ適用可能; パフォーマンス上の主要な関心事ではない
すべてのところに ValueTask を推奨	同期完了が頻繁なホットパスのみ
DI サービスの new HttpClient() をフラグ立て	IHttpClientFactory が既に使用されているかどうかを確認
動的パターンで [GeneratedRegex] を提案	パターン文字列がコンパイル時リテラルの場合のみフラグ立て
CollectionsMarshal.AsSpan を広くに提案	ベンチマークされた証拠があるウルトラ ホットパスのみ; 複雑さと脆弱性を追加
微最適化で unsafe コードを提案	絶対に必要な場合を除き unsafe を避けてください — パフォーマンスが問題にならない微最適化には推奨しないでください。Span<T>、安全コンテキストでの stackalloc、ArrayPool などの安全な代替案は、パフォーマンス ニーズの大多数をカバーしています