| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
两条互相独立、均不改变保留集合与查询结果的优化：
1) 扫描去装箱：latestRumorFor / rumorIsDuplicate 用 `=` 比较 [<Struct>] 的
NpcId/RumorId（含 RumorId option）会走泛型结构相等并逐条装箱（实测 ~24 B/条，
Sim.chat 单独测得 N=16000 时 393,736 B/次、随 N 线性）。改为先解构底层
int/int64 再比较；Parent 用 int64 option 比较替代 RumorId option 结构相等。
语义完全等价，扫描不再逐条分配。
2) 裁剪判定 O(1)：World 新增派生镜像 RumorCount/RumorOldestDay（不参与存档，
读档由列表经 rumorWorkingSetStats 重建）。appendRumor 用「count+1>capacity
或 min(oldest,day)<cutoff」O(1) 判定，仅真需裁剪时才走 trimRumors；旧 consRumor
每次追加都 rumorsNeedTrim 全表扫一遍。条件与 needTrim 逐字等价，保留集合相同。
等价性验证：5 天 2000 聊天/天跑两遍 WorldSave.save 逐字节相同，
RumorCount/RumorOldestDay 与对列表重算一致（count=8000、oldest_day=1）。
Kernel 长跑基准 30 NPC × 2000 聊天/天（--rumor-bench D 30 2000）：
days 修复前 alloc / ms 修复后 alloc / ms
3 930,716,456 / 1626.7 482,716,192 / 1511.3
30 13,419,045,864 / 12182.5 4,884,067,640 / 8879.6
60 27,297,668,608 / 23769.7 9,774,660,360 / 17078.2
60 天分配 -64%、耗时 -28%，retained_id_checksum=927964000 前后一致。
门槛：final_digest=953775FAEB2F... 三次一致、performance_determinism=PASS；
Kernel 92 / Desktop 143 全绿；--cost-probe 1/5 天 18.7s/18.8GB、90.4s/94.6GB
（全模拟分配由逐 tick NPC 快照主导，谣言子系统占比很小，故全模拟基本持平）。
|
