make RecursiveExtractor faster

[zangetsudo]

1. i have went though the souce code, and found that the 'AreIdentical' function which will do a full compare with the existed files which in the parent list, i dont know how it's necessary to compare all the file content, rather then the file names
2. it's possable to do Recursive Extract in real-parallel with https://www.isolineltd.com/blog/how-to-extract-a-zip-archive-in-parallel.html ?? becuse current version is very-very slow under my test.

regards, mike

[zangetsudo]

very much thanks for your PR #209, wait for Merge

[zangetsudo]

PR #209 ：
test result：29.17 (29.17s total)
version without PR: 27.48 (27.48s total)
got opinion from AI:
If your scenario involves a few large files or deeply nested large files, these optimizations have limited effect, since data copying and disk I/O (when large files exceed memory thresholds) still happen.

[zangetsudo]

the substream will be copy to anther stream if need, wihich make a lot of IOs.
the idea is , can we just put a ref counter to the FileEntry，if we need we just reuse it from parent.

[gfs]

zangetsudo if most of the time is spent on I/O then I'm not sure there's really much to optimize away - thats the actual limitation of reading the file off the disk.

I am not sure what you mean by a ref counter to the file entry and 'reuse it from the parent' - the architecture of Recursive Extractor is generic across many different formats and yields each file from an enumeration of the detected files. It would be significnatly more processing and IO to discard children and reprocess them from a parent later - and without enumerating the children you would not be able to recursively detect and enumerate sub archives.

[zangetsudo]

how can i found the real limitation of 27.48s, where can i put log to find the top consumption of the code ?