把 compute_ms 拆成排队与纯计算，据此否掉换机器这个方向

compute_ms 一直是「提交进程池到拿到结果」的墙钟时间，排队和纯计算混在一个
数里，所以「加核有没有用」只能靠猜——这也是原先打算在 AWS 开第二台比 CPU
的依据。

worker 内部自己计时，连同父进程传入的提交时刻一起回传，拆出 queue_ms 与
inner_ms。实测中位 3ms / 695ms：2 个 worker 跑 3 个币并不排队，因为三个币的
收盘消息错峰到达。瓶颈全在单线程，加核压不到。

顺带把 README 里的内存数据从臆测的 1.5GB 改成实测 410MiB，并注明跨站点比
CPU 收益有限。

Co-authored-by: Cursor <cursoragent@cursor.com>

research/live/shadow_signal.py

@@ -31,6 +31,7 @@ Hummingbot 的 asyncio 循环里会把行情处理一起卡住，所以必须隔
 from __future__ import annotations
 
 import os
+import time
 import warnings
 
 warnings.filterwarnings("ignore")
@@ -153,8 +154,27 @@ def _rebuild(rows) -> "object":
 
 
 def compute_packed(payload: tuple) -> dict:
-    """ProcessPoolExecutor 的入口：收 (l_rows, h_rows, entry_px)。"""
-    l_rows, h_rows, entry_px = payload
+    """ProcessPoolExecutor 的入口：收 (l_rows, h_rows, entry_px[, t_submit])。
+
+    返回里带上 `queue_ms` 与 `inner_ms`，把父进程看到的墙钟时间拆开：
+
+        compute_ms（父进程测）= queue_ms + 反序列化 + inner_ms + 回传
+
+    这个拆分决定「加核有没有用」。排队占大头说明 worker 数不够（币数多于
+    worker 数时，同一秒收盘的币只能排队），加核直接见效；纯计算占大头说明
+    单核性能受限，加核帮不上，得从算法上改成增量更新。
+    两者混在一个数里就只能靠猜。
+    """
+    t_start = time.time()
+    l_rows, h_rows, entry_px, *rest = payload
+    t_submit = rest[0] if rest else None
+
+    t0 = time.perf_counter()
     df_l = _rebuild(l_rows)
     df_h = _rebuild(h_rows) if h_rows else None
-    return compute(df_l, df_h, entry_px)
+    out = compute(df_l, df_h, entry_px)
+    out["inner_ms"] = int((time.perf_counter() - t0) * 1000)
+    # 同一台机器，父子进程时钟一致，可直接相减
+    out["queue_ms"] = int((t_start - t_submit) * 1000) \
+        if t_submit is not None else None
+    return out