extract very slowly

[fan-fanf]

This zip file is about 300 megabytes long and contains thousands of small files and folders，When I use 3.2.0 to extract is fast, but recently when I use 4.0.0 or 4.0.9, both 7z and zip compressed files are very slow, taking 90 seconds,why?Here is my code

bit7z::Bit7zLibrary` lib{ "7za.dll" };//7z.dll
bit7z::BitFileExtractor extractor{ lib, /*bit7z::BitFormat::SevenZip |*/ bit7z::BitFormat::Zip };
extractor.extract("D:/User/test1.zip", "D:/out");

[rikyoz]

Hi!
Sorry for the late reply.
This is really strange!
I need some more details:

• Which compiler and which version are you using?
• How fast is the 3.2.0 in seconds?
• Could you provide the zip file?

Thank you!

[fan-fanf]

Thank you for your reply. Please test with the attachment.   I am sure it is very slow. 范 ***@***.***  

…

------------------ 原始邮件 ------------------ 发件人: "rikyoz/bit7z" ***@***.***>; 发送时间: 2025年1月17日(星期五) 凌晨5:05 ***@***.***>; ***@***.******@***.***>; 主题: Re: [rikyoz/bit7z] extract very slowly (Discussion #272) Hi! Sorry for the late reply. This is really strange! How fast is the 3.2.0 in seconds? Could you provide the zip file? Thank you! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[rikyoz]

Sorry, there's no file attached to your comment. Maybe you're responding via email instead of GitHub and the file got lost. Could you try uploading it again using the GitHub interface? Thank you very much!

[fan-fanf]

I can't upload such a large attachment.
I used this zip file at the time, and the download link is:
https://mirror.library.ucy.ac.cy/eclipse/technology/epp/downloads/release/2024-09/R/eclipse-java-2024-09-R-win32-x86_64.zip
Please download and test it, thank you.
Looking forward to your results.
Thank you !

[rikyoz]

Thanks for the download link, it helped me reproduce the problem.
I still need to investigate it further, but from some quick tests it seems that the problem is related to issue #224, which was actually about compression, but both operations use the same code to read from and write to the file system.
Long story short, bit7z v4.0 uses C++'s standard file streams to handle file operations in a cross-platform way. Unfortunately, the performance of standard file streams sucks.
In recent patch versions of v4.0, I implemented some workarounds to mitigate the issue, but the problem is still there.
For the next v4.1 (branch develop), I basically rewrote the file handling code to use the operating system's native functions, which greatly improved performance, and is now closer to v3.2 (which used 7-Zip's code directly instead).
You can test this branch if you like.
There's still some room for improvement though, so I'll definitely be working on that to make up for the lost performance from v3.2.

[fan-fanf]

That's great. Thank you!   范 ***@***.***  

…

------------------ 原始邮件 ------------------ 发件人: ***@***.***>; 发送时间: 2025年1月21日(星期二) 凌晨5:50 收件人: ***@***.***>; 抄送: ***@***.***>; ***@***.***>; 主题: Re: [rikyoz/bit7z] extract very slowly (Discussion #272) Thanks for the download link, it helped me reproduce the problem. I still need to investigate it further, but from some quick tests it seems that the problem is related to issue #224, which was actually about compression, but both operations use the same code to read from and write to the file system. Long story short, bit7z v4.0 uses C++'s standard file streams to handle file operations in a cross-platform way. Unfortunately, the performance of standard file streams sucks. In recent patch versions of v4.0, I implemented some workarounds to mitigate the issue, but the problem is still there. For the next v4.1 (branch develop), I basically rewrote the file handling code to use the operating system's native functions, which greatly improved performance, and is now closer to v3.2 (which used 7-Zip's code directly instead). You can test this branch if you like. There's still some room for improvement though, so I'll definitely be working on that to make up for the lost performance from v3.2. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>