 jackyu66gitandCursor
|
bfdb2f2e2a
|
引擎四处「算了没人要的东西」，append_bar 13.9ms → 6.6ms
服务端把增量上线后回传两个热点：add_indicators 为加一根重算全表（占 34%）、
cal_bi_list 整表重扫（51%）。顺着查下来四处都不是算法慢，是算了没人读的结果。
1. cal_trend 挂到 lean 下。它不是笔的依赖（bi.py:221 在它自己的循环里读自身
序列状态），服务端 verify_incr_parity 三币 1800 根已对拍定论。web 走非
lean，klc_trend 图层不受影响。
2. check_fx_pattern 删掉拼完就丢的字符串。它把 klu.to_string() 拼成 p 只为
一行注释掉的 print——2000 根上近 3 万次 f-string 加 6 万次 enum 格式化，
而且在 cal_bi_list 内层。klu.pattern 只被 cal_klu_pattern 自己的双K/三K
判定读，不出模块不进 web，所以整个调用在 lean 下也跳过。
3. ChanBI.add_klc 去二次方。去重原本线性扫 klc_list，且每加一根就把整笔所有
KLU 的 macdhist 重累一遍，往一笔加 k 根是 O(k²)。改成下标集合加
macd_hist/macd_div 惰性求值。这两个值只有背驰判定（bsp.py）读，lean 下
bsp 根本不算。
4. add_indicators 批量挂列。2001 行上 TA 计算合计只有 2.5ms，而 30 多次
df['x']= 要 3.6ms——开销大头是 BlockManager 逐列插入不是计算，改为一次
concat。cal_volume_ratio 里为算一列 rolling 而 copy() 整张 40 列表，一并去掉。
实测（本机，2001 根窗口。服务端基线 21.8ms 是另一台机器，别直接比绝对值）：
append_bar 13.9 → 6.6ms
└ rebuild_bi_zs 8.7 → 2.8ms
└ add_indicators 4.4 → 3.5ms
TF_DF lean 49.8 → 32.9ms
TF_DF full 72.7 → 64.9ms
对拍用 git worktree 检出改动前的提交，同一份 BTC 1m 4000 根跑 38 项指纹：
full 模式 19 项全部一致（web 那条路没动）；lean 模式差 2 项，正是设计要它差
的 klc.trend 和 klu.pattern，而 lean 下 bi/zs/seg/bsp/dataframe 全部一致——
这就是「这两个字段没人读」的实测证据：打空它们，下游一位不变。
瓶颈已经换位置了。新增 probe_inner.py 拆 inner_ms 分档：本机 TF_DF 两条腿占
70%、build_htf_zones 13%、htf_fx_timeline 6%，而服务端报的是 chan 构建 22ms /
信号链 86ms，机器差解释不了这个四倍差距。曾怀疑是 payload 反序列化，实测
_rebuild 只有 1.0ms，假设不成立。两边跑同一探针对分档表才能定位。
HANDOFF 顺带修掉一处 5.6 重号（增量落地那节改为 5.7，本节挂 5.71）。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-28 16:01:26 +08:00 |
|