メソッド関連の再計算と線形走査により大規模プロジェクトで実行時間が悪化する

[irof]

事象

JIG 実行内で全命令走査を伴う計算が経路ごとに再実行され、照合も線形走査のため、大規模プロジェクトで実行時間に直結する。

該当箇所と内容（main a3ad929 時点）

• MethodRelations.from(jigTypes) の再計算: inboundAdapters / serviceMethods / datasourceAngles で独立に構築（InboundAdapters.java:20 に TODO あり、UsecaseQueryService.java:33、InfrastructureQueryService.java:19-31）。Swagger用語収集のためだけの構築もある（DefaultJigRepositoryFactory.java:143）
• OutboundAdapters.from（collectTracingJigMethods 込み）も serviceAngles / datasourceAngles / outboundAdapters の各経路で再計算
• MethodRelations.callerMethodsOf が呼び出しごとに全関連を線形走査（MethodRelations.java:44-49）→ callee でグルーピングした Map の導入
• ServiceMethods.contains() が毎回 list() を再構築して線形探索（ServiceMethods.java:39-53）。Usecase.from から呼ばれ二乗オーダー → ID の Set を事前構築
• TypeId.isPrimitive() が String.matches で毎回 Pattern をコンパイル（TypeId.java:83-85）。MethodRelations.from のフィルタから全 MethodCall に対して呼ばれるホットパス → static Pattern 化 or フィールドキャッシュ
• JigMethodId.tuple() が毎回 regex split で再パースされ、OutboundPortOperation.matches の全組み合わせ照合で増幅（JigMethodId.java:29-46）
• DatasourceAngles.from がポート操作ごとに全永続化操作を線形走査（DatasourceAngles.java:34-49）

備考

TypesQueryService にキャッシュ機構が既にあるため、MethodRelations / OutboundAdapters をそこに乗せるのが自然。最も費用対効果が高いのは計算の共有と callee インデックス化。

---

🤖 この issue は Claude Code のコードレビューにより作成されました。