One other thing to pay attention to when dealing with per-frame results is the way in which the average framerate is calculated. And one also has to consider whether the benchmark is a gameplay (normal-time) benchmark, or a timedemo (recorded at x fps) benchmark.
In a gameplay benchmark, consider a situation where you have 10 frames at 100 fps, vs. 10 frames at 50 fps (think of this as a small portion of the total benchmark). In the former situation, if you're taking the sum of the framerates for each frame and dividing by the number of frames, your 10 frames at 100fps will have the same weight towards the final average as the 10 frames at 50 fps.
But the 10 frames at 50fps last twice as long! So, you're disproportionately weighting high-framerate portions of the scene.
How does one fix this? One can instead calculate the average framerate simply by taking the sum of all frames calculated, and divide by the time it took to run the benchmark. Why is this the correct thing to do? Well, I'll take a round-about way of describing it (to facilitate my discussion of the proper calculation for a timedemo-style benchmark).
Consider, first of all, that what we want to do is take the average of the frame rate, but we want to do it in a way that one second at 100 frames per second has the same weighting as one second at 50 frames per second. The obvious way to do this is simply to multiply the frame rate by the time over which it occurred. This is:
(1/time per frame) * time per frame = 1 (for each frame)
And now to get the average time-weighted framerate is to not divide by the number of frames, but the total time for all frames. In the end, we simply have avgfps = (number of frames) / (total time).
Simple enough calculation. Now, though, what we want is the proper measure of the framerate for a timedemo.
Consider that timedemos (in Doom, UT2004, perhaps others) are recorded in a fashion such that each frame rendered represents a constant space in time. That is to say, the timedemos are recorded at a specific rate. So, the time-weighting has already been done for us in the way the timedemo was recorded, and thus the way in which we should calculate the average framerate has similarly changed.
Specifically, the best way to calculate the average in this scenario would be to do what I stated originally: take the average of the framerate for each frame. That is:
avgfps = 1/(number of frames) * sum(1/(time per frame))
If this is not done, then those 10 frames at 50 fps, because they took a longer time to render (even though they represent, in the game, the same space of time as 10 frames at 100 fps), will have a disproportionately-large effect on the average.
