# frame number, frame end timestamp with microseconds, frame time microseconds
1,1489260325.123444,5123
2,1489260325.129121,6777
3,1489260325.135912,5555
This will allow graphing with x axis as a time. This will also allow averaging in time, doing various smoothing algorithms (exponential moving average, moving averages in time, max and min over last 5 seconds, etc), instead just in frames, additionally it allows many other things, like creations of histograms, cumulative distributions, etc, properly normalized between files with different numbers of frames, or with different sections of single play / benchmarks, split on time, and not frames.
Also, the fact that the voglperf show some min/max statistics in the header, means to me, that the file is not being written, until the game ends or logging period ends.
Instead the file should be streamed, and the statistics should be dumped at the end. This way there is no overhead of buffering this in memory. Writing to the file can be done asynchronously from a separate thread with some small buffering if needed. Users can put it in tmpfs, or just leave it to the kernel to flush it really to a disk, so there should be no significant performance impact.
With microsecond accuracy.
csv file example:
This will allow graphing with x axis as a time. This will also allow averaging in time, doing various smoothing algorithms (exponential moving average, moving averages in time, max and min over last 5 seconds, etc), instead just in frames, additionally it allows many other things, like creations of histograms, cumulative distributions, etc, properly normalized between files with different numbers of frames, or with different sections of single play / benchmarks, split on time, and not frames.
Also, the fact that the voglperf show some min/max statistics in the header, means to me, that the file is not being written, until the game ends or logging period ends.
Instead the file should be streamed, and the statistics should be dumped at the end. This way there is no overhead of buffering this in memory. Writing to the file can be done asynchronously from a separate thread with some small buffering if needed. Users can put it in tmpfs, or just leave it to the kernel to flush it really to a disk, so there should be no significant performance impact.