Core: Fix UI slowdown for savestate timestamp reads #12256
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.
Special thanks to @TryTwo for identifying this regression.
On core state changes (Play/Pause for example), Dolphin reads the headers of all savestates associated with the currently running game. Normally this just involves reading the state header, which is uncompressed, thus reads are quick and simple. Changes introduced in #12217 change the behavior when calling
ReadHeader()
inState.cpp
, whose aim is to just get each state's timestamp. Instead of reading just the legacy header,ReadStateHeaderFromFile()
reads what we consider to be the NEW header, which includes version information. To support legacy savestate version checks, we decompress the state using LZ4 to retrieve the version info to copy over to our new header. However, this decompression does not need to occur if we simply wish to read timestamps. If you have several legacy LZ4 states in your Savestate folder, this would cause several decompressions to happen. Toggling play/pause several times in quick succession will lead to the UI hanging.To fix this I can just introduce a boolean for
ReadStateHeaderFromFile()
to exit out if we only need the legacy portion of the header to be read. This fixes the issue for me and seems safe as the callers toReadHeader()
solely reference the timestamp field.