mirror of
https://github.com/libretro/parallel-dc.git
synced 2026-11-10 11:21:28 -10:00
LibretroAdmin
f16d48c35a
A 7z decodes a folder from its start to its end and no other way. The first member asked for had the whole folder decoded before it was answered - for a solid disc image that is everything, before the game was loaded: 45 s with the frontend stopped for a disc with a 512 MB track, on one slow core. A folder of 16 MB or more in a mapped archive is now decoded a slice at a time on a thread of the archive's, which has the archive open a second time for itself, and its members are read as the decoder passes them: a member that is all there is handed out in place as before, and one that is not is read through the calls a large zip member is read through, which wait (an eventcount: no lock) for what the decoder has not reached. With the files in the order 7-Zip has put them in since 2015 - by name - the descriptor and the first tracks come first, and the game is running while the rest is decoded: loaded and running 45.1 s -> 0.15 s 300 frames the same wait first -> 5.9 s, decoding still The bytes end up where they did, held once, and are checked against the folder's CRC when the decoder gets to the end; what is read before that is not yet checked, as with a large zip member. An archive sorted by extension (older 7-Zip, or -mqs) has its descriptor after the tracks, and a disc image whose table is at its end (CDI) is in the same case: the load waits for the decoder to get there, as it always did. An archive that is not mapped, or a build without threads, decodes as before. tools/archive: the lowered-threshold builds decode their 7z fixtures this way while the test reads them, under ASan/UBSan and under TSan. The 7z discs boot, with a state saved and loaded.