通达信公式预警延迟不是网络慢造成的。它由几段耗时相加得到，每一段都有各自的成因与量级；不把这几段分开测，调多久都不会看到明确变化。先接受这个前提，后面的排查才有方向。
下文按耗时段落、轮询间隔、单轮计算量、数据与通道、分段测量五个部分展开。文中界面项以通达信金融终端个人版为准，券商定制版的预警设置项可能有差异。全文只讨论求值过程的时间构成，不涉及任何标的的判断。
一、延迟由几段耗时相加，需要分开量
从条件在数据上成立，到界面上出现提示，中间经过的段落可以拆成四段：
| 段落 | 决定它的因素 | 怎么观察 |
|---|---|---|
| 行情落地 | 行情推送频率、本地行情接收状态 | 把同一时刻的行情报价与另一处报价源对比 |
| 公式求值 | 公式引用的历史根数、函数个数、单只品种的计算路径 | 换一段简单公式做对照，看单轮耗时是否变化 |
| 等待下一个轮询点 | 预警的轮询间隔设置 | 把公式换成恒成立条件，测两次提示之间的间隔 |
| 提示发出 | 提示方式（弹窗、声音、列表刷新） | 同一条件下换一种提示方式对比 |
四段是相加关系，通达信公式预警延迟等于四段之和。其中的第三段容易被当成无关项，但它的量级由设置直接给出：轮询间隔设为 3 秒时，条件成立后可能要在原地等待接近 3 秒才被判断到。这一段构成了延迟的下限。
二、刷新频率：轮询间隔决定了下限
公式预警的工作方式是按间隔轮询，而不是每次行情更新都触发一次计算。这意味着即使公式在极短的时间内算完，提示也只能落在下一个轮询点上。
轮询间隔在预警设置界面里选定。它的取值有几档可选，间隔越短，判断越密集，同时每一轮留给计算的时间也越短。这两件事是一起变化的：
- 间隔设得比单轮计算时间短。上一轮还没算完，下一个轮询点已经到了，实际的判断间隔会被拉长到接近单轮计算时间。此时把间隔调得更短不会改善延迟，反而增加本地负担。
- 间隔设得远大于单轮计算时间。等待时间占主导，缩短间隔能直接降低延迟，直到间隔接近单轮计算时间为止。
- 间隔与单轮计算时间接近。这是配置的合理区间，继续调小间隔收益有限。
三档之间的关系可以用一个动作确认：先把间隔调到允许的最短档位，再逐步调长，观察两次提示之间的实际间隔。调短之后实际间隔没有变化，说明当前的瓶颈不在轮询间隔上，而在单轮计算或提示通道上；调长之后实际间隔跟着变长，说明公式与范围这一段并没有把每一轮的时间占满。
条件:C>0;），范围收到自选股，观察两次提示之间的实际时间间隔。这个数字就是轮询间隔在本地真实环境下的表现。三、本地计算量：单只耗时乘以扫描品种数
本地计算量这一段在通达信公式预警延迟中的占比是可变的，它由两项相乘得到：单只品种的求值耗时，乘以参与扫描的品种数。两项里更容易被忽略的是前一项。
单只品种的求值耗时与公式的写法有关，具体落在三处：
| 写法 | 为什么影响耗时 |
|---|---|
| 往回取值的窗口长度 | LLV(C,250) 与 LLV(C,20) 的比较范围不同，前者每次求值要覆盖更长的历史区间 |
| 函数个数与嵌套层数 | 嵌套调用会把中间结果逐层算出，层数越多，单次求值的路径越长 |
| 跨周期引用 | 在较短周期上引用较长周期的数据，需要在两种周期之间做对应，求值路径比同周期引用长 |
另一项是品种数。全市场扫描与自选股扫描的数量差别很大，两者在单轮耗时上的差距与数量大致同向变化。把预警范围从全市场收窄到自选清单，是降低单轮耗时最直接的一步，不需要改动公式。
{ 求值路径较短的写法：窗口短、常量在文首 }
N:=20;
条件:V>MA(V,N)*1.5 AND C>REF(HHV(H,N),1);
{ 求值路径较长的写法：窗口长、同一量重复计算 }
条件2:V>MA(V,250)*1.5
AND C>REF(HHV(H,250),1)
AND LLV(L,250)>REF(LLV(L,250),1)*0.9;
两段写法在表达的意思上不完全相同，这里只借它说明一件事：同一份逻辑，往回取的窗口越长、重复计算的次数越多，单只品种的求值耗时越长。写公式时把重复用到的中间量定义一次、后面引用变量名，可以省掉一部分重复计算。
品种数这一项有一个容易被忽略的细节：预警范围里的停牌品种与当日无行情的品种同样会进入扫描队列。这类条目没有可用行情，公式在它们上面的求值结果没有意义，但扫描动作本身仍要花费时间。把手动加入的自选清单逐项清理一遍，比在公式里加过滤条件更直接。
四、行情落地与提示通道
这一段与公式无关，但它占的份额需要单独确认，否则公式改来改去也测不出改善。
- 行情落地。本地报价依赖行情推送。推送节奏与本地接收状态决定这一段的基础耗时，它不受公式写法影响。
- 计算位置。预警条件在本地求值时依赖本地行情与本地历史数据；使用云端预警时，判断在服务端完成，本地只负责接收结果，两段耗时的构成不同。
- 提示通道。弹窗、声音、列表刷新三种方式的响应速度不同。同一条件下换一种方式对比，可以判断这一段的份额。
五、分段测量与判断
把四段拆开测，操作上只有三步：
- 测下限。预警条件换成恒成立的条件，范围收到自选清单，观察两次提示之间的实际间隔。这个数字包含轮询间隔与提示通道两段，是本地环境能达到的近似下限。
- 测单轮。把真实条件加回去，保持范围不变，观察间隔的变化量。变化量就是公式求值这一段在单只品种上的耗时体现。
- 测范围。保持条件不变，把范围从自选清单扩到全市场，再观察间隔的变化。变化量与品种数同向。
| 观察结果 | 指向 | 下一步 |
|---|---|---|
| 第一步的间隔已明显长于设置的轮询间隔 | 轮询间隔与单轮计算时间不匹配，或提示通道耗时 | 先确认单轮计算时间，再调间隔 |
| 第二步加回条件后间隔明显变长 | 公式求值这一段占比较大 | 缩短往回取值窗口、消除重复计算 |
| 第三步扩大范围后间隔明显变长 | 品种数占比较大 | 收窄预警范围 |
| 三步都测不出明显变化 | 延迟不在本地计算与范围这两段 | 转向行情落地与提示通道这两段 |
通达信公式预警延迟的排查结论，取决于这三步测出的数字，而不取决于公式的复杂程度看起来如何。最后留一个问题：把范围收窄到自选清单、把往回取值的窗口从 250 根降到 60 根之后，如果实际间隔几乎没有变化，那前面关于本地计算量的推断还站得住吗？测不出变化的那些段落，恰好就是你不需要再动的地方。
本文讲的是求值过程的时间构成与分段测量方法，不涉及具体标的的判断，预警条件输出的是一份满足表达式的清单，不含任何参与与否的结论。站内还有 选股公式与预警 里讲条件与预警对应关系的条目，公式报错与卡顿排查 里讲其它故障的对照表，指标原理与参数 里讲递推类函数的取值方式，可对照查看。
