I wonder if given the age of both this(tearaway), and TLOU if these games were developed when the expected memory in the PS4 was still 4GB - with something like 1.5GB held back for the OS. If the game went from 2.5GB to maybe 6GB in the patch - maybe even more if Sony have lowered the PS4 OS reserved allocation now that a new gen has arrived and Sony can freeze the PS4 feature set - then unpacking data in three parallel 2GB blocks might account for that type of speed improvement.
I know it was speculated by the guy at RadGameTools that the 500MB patch for TLOU wasn't big enough to ship new textures in oodle texture format, and it was also speculated that expanding the existing zlib textures and re-compressing them on a console would take too long. I do wonder if ND did achieve that, but came at it from a slightly different angle.
For a start, 33% of the uncompressed texture footprint is the mipmaps, and with additional GBs of RAM available to old games, generating those mipmaps in parallel to other data loading would certainly save on time - assuming the loading task was HDD read speed bound.
Alternatively(not very likely though
), maybe ND could have compressed the game texture set again offline, but this time using random access zlib, with a view to use partially resident texturing (so mimicking XsX's Sampler Feedback Streaming feature SFS) after patching . With the two compressed sets of the textures ND would then be able to compare what was shipped in the game, with the new compressed set - assuming the the original zlib texture data would all be identical inside the new random access zlib set, but just with additional header info. If they then differenced the two sets, and compressed the difference file into the patch, they could possibly do that with a small patch and then the game would be able to randomly access the existing texture set and use a PRT/SFS technique that would maybe explain reducing loading times by 2/3rds.
And finally(even less likely), despite it being long and time consuming to blindly recompress all the game textures using oodle texture codecs, there is the tiny possibility that ND did the recompression offline, and then just kept the compressor log for the task. Whether having the compressor log to guide a recompression task - if uncompressing the game's current zlib texture set and then recompressing those with oodle texture on a console is achievable is a big if when talking GBs of compressed textures - but maybe if it was just done for the textures at the main loading points - so those load points are much quicker, then maybe it would be possible to replace the game zlib textures with oodle textures as a background task while playing and loading/accessing textures - but that would also be relying on use of RDO settings that would have marginally more noise in exchange for hefty improvements in compression ratios and be regenerating mipmaps at load time.
Probably none of those things have happened, but it is certainly interesting IMO to speculate on how they've manage to make such gains in load times.
