Load content runtime data 'on demand'#8717
Merged
hizzlekizzle merged 2 commits intolibretro:masterfrom May 9, 2019
Merged
Conversation
|
This pull request introduces 1 alert when merging a4785b7 into ba3f164 - view on LGTM.com new alerts:
Comment posted by LGTM.com |
Contributor
Author
|
Okay, just pushed a commit to get rid of that LGTM warning... |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Description
At present, when playtime logging is enabled, the runtime information associated with each entry of a playlist is loaded when the playlist itself is opened. On the vast majority of platforms (and all desktop systems) the performance impact of this is negligible - but on devices with very slow storage (typically Nintendo consoles), once a playlist accumulates ~100 runtime logs then the added delay when opening the playlist becomes noticeable (and annoying).
With this PR, runtime logs are only read when the menu driver presents the associated entries (the values are cached, and only reloaded once the playlist is opened anew). This places an upper limit on the number of runtime logs that can be loaded at any one time:
For RGUI, this is 17
For XMB, this is ~11
For Ozone, this is 1 (Ozone doesn't use playlist sublabels, so it can handle this more efficiently)
GLUI unfortunately loops through all entries regardless of what is shown, so no benefit is seen here...
Basically, this means that playlists can be arbitrarily long, and have an arbitrary number of runtime logs, and performance will not suffer on weak devices (unless they use GLUI, but this is not available on console platforms anyway).
Note that further improvements are possible with changes to the menu entry code - I'll look into this later.