nicolas @ uucidl

Use Frame Time Not Frame Rate When Working On Performance

May 21, 2016 by nicolas, tagged projects

Hi, I've heard you were working on an interactive graphical application, and that you're doing your best to give it a smooth frame rate.

Try to ignore changes in frame rate when measuring or improving the performance of a component within the complete system. Remember instead your frame time budget (e.g. 16ms for a 60hz target) and track the time your component takes within that budget.

To understand why, look at the relationship between your efforts and the measurements.

Since frame rates are inversely proportional to frame times, for the same optimization (a delta in time: Δt), you will observe different frame rate deltas when you start from different frame times. (e.g. in different testing conditions or if the system changes)

This relationship is not linear, with ratehz = 1/times and thus ratehz = 1/(times + Δt), which makes it difficult to reason with frame rates.

empty Δt=4ms Max(time)=80ms

In order to deliver a smooth experience, what matters is whether your complete system meets your per-frame budget, such as 16ms for a 60hz target.

That budget is best monitored with deltas in time, as for given workloads the deltas can be added to predict the overall performance of the system.

Some examples

For the same gain in frame time budget of 1ms:

If the system was spending 15ms of rendering time per frame, an improvement of 1ms would increase the frame rate by about 5 frames or 7%.

If however that system was spending about 6ms in total the same optimization effort would come out as an improvement of 34 frames or 20%.


Thanks to Gregor Klinke for reviewing a draft of this text.


  • Frame: a coherent drawing (or render) on the screen representing an instant in an animation or simulation
  • Frame rate: Frame Per Second, FPS.
  • Frame time: Time Per Frame, TPF