Every good programming technique

[rainwarrior]

By spreading it over more frames.

Spreading it over frames is a type of optimization of its own. This is completely orthogonal to "consistent execution time". Though if this is what was meant by consistent execution time, then I apologize for my confusion. (I recommend the same concept using the term "load balancing" above.) I was treating as meaning only changing the code so it performs the same function, but with consistent execution time.

Maybe there's a lot of testing and branching that only saves time if there's less work to do.

Saving time if there's less work to do gives more CPU time for other objects, though. If you're talking about a collection of the same object all synchronized to hit a spike at the same time, yes it's worse, but again the suggestion is "load balancing". If you can coordinate so they're not all spiking at the same time, the saved CPU in the "less work" instances can make more room for the worst case instance.

[Rahsennor]

Make it so the amount of CPU time doesn't vary wildly from one frame to the next.

I interpreted this as a goal, not a method. Probably because it's already my number one optimization rule: "it's not what you do, but when you do it".

[tepples]

Load balancing is why I have a bunch of things in Thwaite and RHDE set on a 5-frame timer to run once every tenth of a second. There are five time slots, in each of which I schedule a different periodic task. (The sixth slot is empty on NTSC and doesn't run at all on PAL.)

[psycopathicteen]

By spreading it over more frames.

Example from the NES scrolling code I'm working on: the old routine unpacks a 32-pixel-wide column at a time. In terms of cycles per byte it's easily the faster of the two. The new routine only unpacks an 8-pixel wide column at a time. It takes more cycles per byte, because it has to perform the same metatile decoding more than once, but it unpacks fewer bytes at a time.

When scrolling at 8 pixels per frame, the first routine is idle for three frames and spikes wildly every fourth. The second routine takes the same amount of time every frame. The total work over four frames is higher, but the worst case is significantly lower. If I only need to scroll 8 pixels per frame, the second routine will cause fewer lag frames despite being less efficient overall.

It's funny how much I see this type of optimization misapplied to the SNES, to ridiculous extremes like "You should only update a couple tiles per frame, and limit scrolling to 4 pixels per frame, in order to avoid slowdown" and then complain how their game "lags" whenever they try to move their character fast.