 jackandCursor
|
6c843639d5
|
影子路径开 lean 模式，实测完整链路 1410 → 683ms
拉到新引擎后在服务器侧直接实测，没有沿用 3.4 倍那个换算——那是在旧代码上量的。
先做等价性验证。不能直接引用 step46 的对拍结论：它固化的是 bsp_list 那条链的
哈希，而影子路径走 find_fast_bsp3 + build_htf_zones + htf_fx_timeline +
attach_htf_context，两条链读的东西不一样。所以新建 verify_lean_parity.py 在
这条路径上逐根对拍 compute() 的每个返回字段。
其中一个坑：随机取窗口测不到信号分支。信号密度约 1/2000 根，头 12 个窗口命中
0 个，「一致」只覆盖了早退路径。改成一半窗口对齐到已知信号根，命中率才上来。
最终 180 窗口 / 两模式各 90 命中 / 零分歧。
生产实测（inner_ms，容器内同口径）：
compute_ms 646 → 132ms 4.89x
inner_ms 612 → 128ms 4.80x
lag_signal_ms 1410 → 683ms 完整链路，落回 800ms 线内
比 3.4 倍更好，因为是引擎 ~3.5x 叠 lean ~1.35x。
两点判读上的订正：
- lag_data_ms 那 576→490ms 是噪声，不要记在引擎账上。均值 721±36 vs
740±127，重叠；而且引擎本来就影响不到交易所与网络那一段。
- 仍有 44% 的根超 800ms，但尾部现在完全由数据腿主导（lag_data P90 1482ms
vs compute P90 237ms）。计算既不是瓶颈也不是尾部主因了，继续压计算换不到
尾部改善。800ms 那道闸取的是最近 30 根的中位数，683ms 已满足。
start.sh 加 SHADOW_LEAN（默认 1），设 0 可退回 full 复量两模式差异。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 04:24:08 +08:00 |
|