Timer Initialization and Accuracy Fix #1356
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The generalization of the main loop for SDL introduced a regression I finally caught reviewing my benchmark in #1289. The timing variables should be initialized just before input and before ANY user events (e.g, game start, room start, or the create event in my case) are fired at all, otherwise
get_timer
is completely inaccurate.This occurred on Win32 where we don't query whether to use the high quality performance counter until the timing is initialized. All of the microsecond times I reported in my benchmark for #1289 are basically inaccurate to within 1/1000th of a microsecond. I am going to have to redo the entire benchmark now with this patch to see the actual difference.
I caught the mistake by wondering why none of my changes to the new model creation (in an effort to speed it up again) were affecting the results at all. I continued moving the
get_timer
lower and lower until I was timing the creation of a single slice of cubes. It was then reporting 0 or 15,000, but nothing in between. With this fix applied it is very very accurate and always reports differences of a microsecond or two.Benchmark Update
Because of this issue, I decided I must record the model creation times from the benchmark in #1289 again. The results I am going to share here are relative to that pull request, not this one, because I did a hard reset and retroactively applied this patch. I record for each system the best time out of three tries.
The results basically indicate that, yeah, #1289 did generally increase the create time despite the other advantages. But with this PR going forward, I can accurately measure any optimizations I make to speed the model creation back up again. I can't do that without this change.