I managed to work out a proof-of-concept hack to manually skip the compressed bytes.
The hack doesn't allow multi-nesting of zips (I don't know how reuse the existing forward-only stream for that...yet) so I changed my archive-based tests to match.
Using forward-only streams is ~30% quicker than exporting/parsing nested zip files: 12.63s compared to 17.96s for archive (and 24.15 for DotNetZip-based archive)
This is scanning my large .zipx test file and counting 145,903 files; 16,015 directories; 97 zip files.
This looks very promising!
I love optimizing code but I only need read access and only really for zip files (though support for other formats would be a major bonus).
I have 3 other major projects on the go at the moment and this code is a bit too large and complicated for me to review and make suggestions though I am happy to help where I can with the forward-only-streaming .zip side of things where I can.
I appreciate you are also busy so I won't post any more but I'll wait until you contact me if I can be of help.
The hack doesn't allow multi-nesting of zips (I don't know how reuse the existing forward-only stream for that...yet) so I changed my archive-based tests to match.
Using forward-only streams is ~30% quicker than exporting/parsing nested zip files: 12.63s compared to 17.96s for archive (and 24.15 for DotNetZip-based archive)
This is scanning my large .zipx test file and counting 145,903 files; 16,015 directories; 97 zip files.
This looks very promising!
I love optimizing code but I only need read access and only really for zip files (though support for other formats would be a major bonus).
I have 3 other major projects on the go at the moment and this code is a bit too large and complicated for me to review and make suggestions though I am happy to help where I can with the forward-only-streaming .zip side of things where I can.
I appreciate you are also busy so I won't post any more but I'll wait until you contact me if I can be of help.