検索・データ管理周りの効率化と冗長コード整理

[willybilly981]

BY GPT 5.5

背景

検索件数が増えると重くなる旨はREADMEにも記載があり、静的レビューでも検索処理・CSV保存・UI一覧生成に効率化余地が見られました。実測プロファイルは未実施のため、まずは改善候補として整理します。

改善候補

1. 装備名検索をDictionary化する

対象: src/SimModel/Model/Masters.cs:107-112, src/SimModel/Domain/Searcher.cs:575-590, src/SimModel/Domain/FileOperation.cs:513-522

Masters.GetEquipByName が呼び出しごとに全装備リストを Union し、線形検索しています。検索結果生成やマイセット読込で繰り返し呼ばれるため、装備数と呼び出し回数に比例して重くなります。

対応案:

• マスタ読込後に Dictionary<string, Equipment> の索引を構築する
• TryGetEquipByName を追加し、空の Equipment を返す挙動を段階的に置き換える
• Searcher 内では変数名から再検索せず、変数作成時に Variable -> Equipment または name -> Equipment を保持する

2. 護石検索時の一時的な除外解除でCSV保存が多発している

対象: src/SimModel/Service/Simulator.cs:226-235, src/SimModel/Service/Simulator.cs:292-303, src/SimModel/Domain/DataManagement.cs:134-158

SearchCharm で護石の除外・固定を一時解除する際、DeleteClude / AddExclude / AddInclude を個別に呼んでいます。これらは毎回 SaveCludeCSV を呼ぶため、検索開始前後に不要なディスク書き込みが複数回発生します。

対応案:

• 一括更新用APIを追加し、CSV保存は最後に1回だけ行う
• 可能であれば、検索条件側で「護石の除外・固定を無視する」指定を渡し、Masters.Cludes 自体を変更しない

3. Searcher 内の対象装備列挙とスロット係数設定が重複している

対象: src/SimModel/Domain/Searcher.cs:242-243, src/SimModel/Domain/Searcher.cs:365-366, src/SimModel/Domain/Searcher.cs:428-429, src/SimModel/Domain/Searcher.cs:489-529

同じ対象装備リストを SetVariables / SetObjective / SetDatas で毎回組み立てています。また、スロット係数は武器・防具・全スキルで似た処理が3回展開されています。

対応案:

• コンストラクタで TargetEquips を一度だけ作る
• スロット係数設定を共通メソッド化する
• SlotCalc 結果と符号反転処理をまとめ、配列生成とループを削減する

4. FileOperation の保存処理に副作用と重複計算がある

対象: src/SimModel/Domain/FileOperation.cs:420-422, src/SimModel/Domain/FileOperation.cs:488-501, src/SimModel/Domain/FileOperation.cs:536-538, src/SimModel/Domain/FileOperation.cs:713, src/SimModel/Domain/FileOperation.cs:935

装飾品所持数読込で Dictionary に対して Where(...).FirstOrDefault() を使っており、TryGetValue で十分です。また、マイセット保存・読込時に追加護石CSVとアーティアCSVを再保存しており、保存対象が広がっています。

対応案:

• decoCounts.TryGetValue(deco.Name, out var count) に置き換える
• Masters.MySets の使用中IDを HashSet<string> にして、護石・アーティア保存時の Any 繰り返しを避ける
• SaveMySetCSV / LoadMySetCSV から別CSV保存を直接呼ぶ設計を見直す
• SaveArtianCSV の使用中判定が set.Charm.Name を参照しているため、アーティアなら set.Weapon.Name が妥当か確認する

5. 除外・固定画面の一覧生成処理が冗長

対象: src/WildsSim/ViewModels/SubViews/CludeTabViewModel.cs:304-403, src/WildsSim/ViewModels/SubViews/CludeTabViewModel.cs:411-497

防具一覧と武器一覧で、フィルタ・設定済み絞り込み・仮番号ごとの行生成が似た形で実装されています。武器種ごとのリストも14種類を手書きしており、武器種追加時の修正漏れリスクがあります。

対応案:

• 武器種リストは Enum または設定配列から生成する
• Masters.Cludes.Select(c => c.Name).ToHashSet() を使い、設定済み判定を高速化する
• 行生成処理を共通化し、表示カテゴリだけ差し替える

6. 理論値護石生成の重複判定がO(n^2)

対象: src/SimModel/Model/SearchCondition.cs:264-325

MakeRelatedCharms で生成済み護石との重複確認を毎回リスト全走査しています。理論値護石検索では候補数が増えやすいため、重くなる可能性があります。

対応案:

• スロット情報とスキル情報を正規化したキーを作る
• HashSet<string> で重複判定する

受け入れ条件

• 通常検索、追加スキル検索、護石検索、理論値護石検索、理論値アーティア検索の検索結果が既存挙動と一致する
• 除外・固定、マイセット、追加護石、アーティアのCSV保存結果が既存フォーマットと互換である
• 主要操作で不要なCSV書き込み回数が減っている
• 可能であれば、検索開始から結果表示までの時間を変更前後で比較する

優先度案

• P1: 装備名検索のDictionary化、護石検索時のCSV多重保存削減、FileOperation の保存副作用整理
• P2: Searcher 内の重複整理、理論値護石生成のHashSet化
• P3: 除外・固定画面の一覧生成共通化、細かなLINQ置き換え

[EXXXI]

1,2,3は #98 のリファクタリングで仕組みごと変える予定です。
4の副作用はFileOperationじゃなくてDataManagementに持っていきたいですね。
5,6もHashSetの利用は検討したいですね。

アセンダンス発売までには色々と整備したいですが、しばらく時間がとれなさそうなので構想だけ溜まってます。