Takeshi
b84bade045
Preserve production code, regression fixtures, audio assets and provenance, test infrastructure, and the original-completion plan and progress ledger. Final game and Windows acceptance remain pending; excluded local artifacts and native experiments are not part of this snapshot.
37 lines
5.1 KiB
Markdown
37 lines
5.1 KiB
Markdown
# P28-01 実 Runtime 代表負荷の再監査
|
||
|
||
指定の20,000マス・200客・50職員・150施設に行列・物流・イベントを付けた、現版の実 Runtime 全体の受入証拠は未確認である。現在の通常 Operations の人口上限は100で、200客の通常営業受入へそのまま進めない。人口上限200への生改変や保存基準値変更は採用していない。
|
||
|
||
この文書はソースの読み取りと driver 案である。新しい性能測定は実施しておらず、root の全157回帰実行中に CPU を競合させていない。読み取ったファイルのSHA、時刻、詳細は `performance_audit.json` に記録した。
|
||
|
||
## 既存 fixture の再利用範囲
|
||
|
||
| 既存成果 | 確認済みの範囲 | 代表負荷との差 |
|
||
|---|---|---|
|
||
| `perf_mvp_001_harness.gd` | 実サービスを別々に作り、20000/200/50/150、行列500、未完物流200、イベント50を独自ループで処理 | SimulationRuntime/GameClock/実保存パッケージ/UI/GPUを通さない。200×50×2のマップはRank7正規境界に合わない |
|
||
| `profile_production_scene.gd` | 実Runtimeとmain画面、Tick phase、x1/x3、snapshot/digest、UI同期更新を測る | PixelTowerDemoの7サービス施設・4職員という小シーン。自動保存無効、描画/GPU対象外 |
|
||
| `test_runtime_actor_cycle.gd` | 公開commandで建設・職員・客を登録し、実Tickで業務・物流・サービスとsnapshot replayを検証 | 小規模。200客の実保存・読込・持続負荷を証明しない |
|
||
| `test_save_preflight.gd` | 大型Worldの保存サイズ測定 | `full_runtime_20000_cell_acceptance=false` を明示する |
|
||
|
||
モデルの測定値と小Runtime測定値を、指定の全Runtime負荷の合格値へ読み替えない。
|
||
|
||
## 100客上限と200客診断
|
||
|
||
`OperationsCoordinator.DEFAULT_CONFIG.population_cap` は100（`scripts/operations/operations_coordinator.gd:83`）。Runtimeの `enable_production_operations()` は正規既定値で生成し、上限overrideを受け取らない（`autoload/simulation_runtime.gd:1446`）。有効時の `spawn_guest` は上限を拒否する（5892）。保存復元は正規configとの厳密一致を要求する（3160、3828）。従って手動cap200変更は正規保存契約と一致しない。
|
||
|
||
Operationsを無効のまま初期化する診断ではこの上限guardが適用されない。公開 `spawn_guest` は客・財布・経路actor・進行生涯数を接続し、GameClockは実Runtimeの登録phaseを走らせる。`save_to_path`（3991）と `load_from_path`（4019）も利用できる。200客の保存＋実Tickは静的には実施候補になるが、まだ200客を作成・保存・読込していない。**production Operations enabled mixed load未受入**を全結果に付ける。
|
||
|
||
Rank7の正規境界はx=-60〜60、y=-40〜56、2層で23,474座標slot。20,000はこの境界内で準備する。Rank6は13,774slotで足りない。GameStateだけRank7へ書き換えたり、モデルの200×50境界をコピーすると、Progression/World/経路投影の復元検証と一致しない。公開昇格commandの条件を満たすfixture、または同版で検証済みのRank7保存が必要で、その既存成果は未確認である。
|
||
|
||
## 最小 driver 案
|
||
|
||
1. root採用版のソース地図、Godot binary、機種、seed、driver、専用一時保存先をpinする。
|
||
2. 実GameClock/GameState/SimulationRuntimeからOperations無効の診断を作り、正規昇格履歴と境界内20,000マスを準備する。世界・SpatialSubslot・RouteAdapter・施設インフラ投影の全相互参照を検証する。
|
||
3. 公開commandで150施設を完成させ、50職員へシフト・業務を設定、200客へ実財布を作成する。行列、在庫、未完物流、イベント候補を実サービスへ接続し、開始時と終了時の実数を報告する。診断用の在庫・資源補給は通常プレイ証拠へ昇格させない。
|
||
4. 測定前にRuntimeの実保存パッケージを作成し、別Runtimeで読み込み、完全snapshot/digest一致を要求する。失敗したfixtureでは時間だけ測って合格にしない。
|
||
5. 同一checkpointへ戻してx1/x3の全Tick、phase、経路、snapshot、digest、UI同期更新、最大停止、実保存/読込を別々に測る。平均/P95/最大/標本数/区間/速度を保存し、対象が減ったら減少数も報告する。
|
||
6. Operations有効は100客以下の正規診断として別に測る。200客有効の本番代表負荷は未受入として残す。回帰と同時測定せず、同条件を反復する。
|
||
7. 描画とWindowsは別の実機受入とする。同一EXE/PCK/ZIP、CPU/GPU/RAM、解像度/拡大率、D10の描画目標が必要である。
|
||
|
||
現コード予算はx1平均4ms、x3 P95 12ms、経路P95 2ms、最大main-thread停止50ms、保存5秒、読込8秒（`scripts/core/performance_budget.gd:17`）。新測定はまだない。200客の本番上限、正規Rank7 fixture、通常営業に必要な未確定施設値、持続する行列/物流/イベント、Windows実機と描画目標が受入の残件である。
|