Day 018 Timing results

As an experiment, I wanted to know how much time is spent "sleeping". I removed the sleep code
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
//...
#if 0
LARGE_INTEGER WorkCounter = Win32GetWallClock();
real32 WorkSecondsElapsed = Win32GetSecondsElapsed(LastCounter, WorkCounter);

// TODO(casey): NOT TESTED YET!  PROBABLY BUGGY!!!!!
real32 SecondsElapsedForFrame = WorkSecondsElapsed;
if(SecondsElapsedForFrame < TargetSecondsPerFrame)
{                        
    //...
}
else
{
    //...
}
#endif
//...

The before and after results I find interesting

Handmade with sleep
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
38.72ms/f,  0.00f/s,  92.69mc/f
38.94ms/f,  0.00f/s,  93.22mc/f
39.27ms/f,  0.00f/s,  94.01mc/f
...
40.31ms/f,  0.00f/s,  96.51mc/f
38.76ms/f,  0.00f/s,  92.79mc/f
...
40.80ms/f,  0.00f/s,  97.68mc/f
...
40.91ms/f,  0.00f/s,  97.93mc/f

Remove sleep loop
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
29.65ms/f,  0.00f/s,  70.98mc/f
14.18ms/f,  0.00f/s,  33.95mc/f
...
15.06ms/f,  0.00f/s,  36.05mc/f
13.40ms/f,  0.00f/s,  32.09mc/f
...
14.20ms/f,  0.00f/s,  34.01mc/f
...
12.89ms/f,  0.00f/s,  30.86mc/f
...
13.36ms/f,  0.00f/s,  31.99mc/f
...
16.86ms/f,  0.00f/s,  40.35mc/f
...

What this means to me is that the sleep code granularity is low (not surprising) and artificially pushes the fps past the target. We have room to work with for 30 fps and 60 fps isn't quite out of the picture.

- tim
I wouldn't worry about this Sleep code much. Around day 19x when working on debug UI Casey removed this sleep functionality, because it was taking too much time (or similar reason).
Makes sense.

I'm not worried as much as surprised. I was curious about time spent "sleeping." I wasn't expecting that we're sleeping more than running. But that's we we should be.

- tim