Improve LuaTimer performance #5453
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Use a C++ sorted deque to store timeout entries, significantly reduce overhead of iterating the list of timers every frame - Timer insertion cost is higher (roughly O(N/2) worst-case), but that's generally less of a problem when timers have a long timeout and they're created irregularly - Use std::lower_bound for log-search in the timeouts list
- Also document LuaSerializer for NaturalDocs as well
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 first of several PRs being split out from the Scout Mission branch. Don't expect a long shelf-life before merge.
This PR refactors the LuaTimer implementation to use a sorted C++ queue to store a list of "timeouts" rather than walking an unordered Lua table to see if a timer is ready to fire yet. This should improve worst-case per-frame performance of the timer implementation, though it does make the worst-case insertion performance of queuing a new timer
O(log N) + O(N/2)instead of a classic hashtable insertO(log N).If this does prove to be an issue in the future with many 100s of timers being created each second, another approach might be a sorted intrusive-linked-list.EDIT: that's not an option because of theO(N)search time to find an insertion point...LuaTimer has not (yet) shown up as a major performance issue, but this work also lays the groundwork for future improvements like cancelling timers and #5222.