TermiNexus
2ba38ae842
fix(Phase2Translator): 并行 worker 数不再按可用内存降级串行，改为"预分配校验 + 强制预留"（TPC_JOBS 可显式覆盖）
现象：同一条命令的编译时间在 ~400s 与 ~1180s 两档之间随机跳（PROF 目录当日
366s~2239s），用户反馈"耗时不降反增"。
根因（三份 profile 实证）：
- 旧 _PickWorkerCount 用 `by_mem = max(1, avail_mb // per_worker_mb)` 按**可用**
物理内存夹 worker 数：可用稍紧（<~2.8GB）就整体降为 1 ⇒ **静默退回串行**。
其文档字符串自己就写着"76 文件逐个翻译 1180s，并行时 ~400s，波动 2-3 倍"。
- PROF/20260930_224857（438.40s）：主进程 _translate_file **0 次**、
StructGen/HandlesImports/HandlesClassDef **0 条记录**、总调用 7.28 亿
⇒ 翻译在 worker 进程里做完了（未 profile），主进程只在等 → **并行档**。
- PROF/20260930_231916（1048.55s）与 20260930_235354（1168.15s）：
_translate_file **75 次全在主进程**、_parallel_translate_worker/_batch 0 次、
总调用 19.6 亿 ⇒ **串行档**（1180s 档）。
⇒ 拿 438s 当基线比 1168s 是"并行 vs 串行"。本次 A/B（同为串行、总调用
19.616 亿 vs 19.631 亿）里各项优化均为正收益（_RewritePlain −5.0s、
__exit__ −1.5s、re.match+_compile −1.3s、_RewriteQuoted −0.75s…）；
+12% 属机器波动（同一批 C 函数在调用次数不变下变慢 25%~73%）。
改动（口径由用户定：不降级 + 预分配内存避免波动 + 强制要求预留内存）：
1. **不降级**：删掉"内存紧就退串行"。worker 数 = min(cpu_count, n_files)，
不再因可用内存抖动而变化。
2. **预分配校验 + 强制预留**：新增 _MemStatus()（读可用/总量）与
_ProbeReserveMb()——按 base×per_worker_mb（翻译 350 / 编译 400）分块**真正
提交**该预算（峰值=预算），成功后立即整体释放，紧接其后创建 worker 进程
由 OS 复用这批页。等于先向 OS 确认"这笔预算确实拿得到"，而不是只看含大量
可回收页的 ullAvailPhys。
3. **fail-fast**：可用内存 < 预算、或预分配校验提交失败 ⇒ RuntimeError 报出
"需要 X MB（N worker × M MB）/ 当前可用 Y MB / 总量 Z MB"，由使用者释放内存
或**显式** TPC_JOBS=N 重跑（N=1 即显式接受串行）。不再静默降级。
4. 新增 TPC_JOBS=N 显式覆盖（跳过校验，使用者自担内存风险）。
5. 每次决策都打日志：显式指定 / 读不到内存状态 / 预分配校验耗时 / 最终 workers。
已知取舍：内存确实不足时编译会**直接失败**（这是"不降级"的应有语义），出路是
释放内存或 TPC_JOBS=N；预分配校验会短暂占用峰值=预算的内存（约 1GB/秒级耗时）。
未动（下一步候选）：串行档的真热点 StructGen._generate_structs（151s 自身 /
480s 累计，被调 36,389 次≈每类 22 次，O(类数²)）。
2026-10-01 00:23:16 +08:00
..
2026-09-14 13:42:14 +08:00
2026-09-30 23:47:36 +08:00
2026-09-28 13:57:04 +08:00
2026-10-01 00:23:16 +08:00
2026-09-26 19:27:22 +08:00
2026-09-30 23:47:36 +08:00
2026-09-12 11:51:42 +08:00
2026-09-28 13:49:28 +08:00
2026-09-26 19:27:22 +08:00
2026-08-17 09:36:38 +08:00
2026-08-17 09:36:38 +08:00