[Bug]: 4.0.x decompress very slow

[wwvv1235]

bit7z version

4.0.x

Compilation options

No response

7-zip version

v23.01

7-zip shared library used

7zxa.dll / 7zxa.so

Compilers

MSVC

Compiler versions

No response

Architecture

x86_64

Operating system

Windows

Operating system versions

No response

Bug description

I created a bit7z decompression test program. The core code relies on the bit7z library and calls decompression-related code. I made two versions: Test Program 1 uses bit7z 3.1.5, and Test Program 2 uses bit7z 4.0.10. The purpose is to test the performance of the two versions on file decompression. The main logic code is as follows:

Main logic code for Test Program 1:
double testBit7zVersion(const std::string& dllPath) {
bit7z::Bit7zLibrary lib(dllPath);//dllPath:7zxa.dll,23.01
bit7z::BitFileExtractor extractor{ lib, bit7z::BitFormat::SevenZip };
cleanOutputDir();
auto start = std::chrono::high_resolution_clock::now();
try {
extractor.extract(ARCHIVE_PATH, OUTPUT_DIR);//ARCHIVE_PATH:output/test.7z
}
catch (const std::exception& e) {
std::cerr << "uncompress failed: " << e.what() << "\n";
return -1;
}
auto end = std::chrono::high_resolution_clock::now();
return std::chrono::duration_caststd::chrono::milliseconds(end - start).count();
}

Main logic code for Test Program 2:
double testBit7zVersion(const std::wstring& dllPath) {
bit7z::Bit7zLibrary lib(dllPath);//dllPath:7zxa.dll,23.01
bit7z::BitExtractor extractor{ lib, bit7z::BitFormat::SevenZip };
cleanOutputDir();
auto start = std::chrono::high_resolution_clock::now();
try {
extractor.extract(ARCHIVE_PATH, OUTPUT_DIR);//ARCHIVE_PATH:output/test.7z
}
catch (const std::exception& e) {
std::cerr << "uncompress failed: " << e.what() << "\n";
return -1;
}
auto end = std::chrono::high_resolution_clock::now();
return std::chrono::duration_caststd::chrono::milliseconds(end - start).count();
}
The test file 'test.7z' is 3.53GB in size.
Six same configuration test machines, configured as follows:

The results of testing the time taken to decompress the same test.7z file on 6 test machines:

On machines 4, 5, and 6, version 4.0.10 of bit7z was more than 6 times slower than version 3.1.5.

Steps to reproduce

No response

Expected behavior

No response

Relevant compilation output

Code of Conduct

• By submitting this issue, I agree to follow bit7z's Code of Conduct

[rikyoz]

Hi!
For reasons of cross-platform compatibility, bit7z v4.0 uses std::fstream internally for reading and writing files. This may explain why you noticed some overhead, as C++ file streams are notoriously slow.
On the other hand, bit7z v3 used part of 7-Zip's source code for the internal file streams, which used low level I/O functions, and thus without std::fstream's overhead.
On the develop branch (the future bit7z v4.1, still work-in-progress, but close to beta), I have completely rewritten bit7z's file streams from scratch to use the low-level I/O functions provided by the OS instead of std::fstream.
In my tests, the overhead has been significantly reduced, to the point that the performance is now really close to that of bit7z v3/7-Zip.
However, I might have missed some test cases.
If you'd like to, you can try testing the develop branch and see if it improves performance for your use cases.

[wwvv1235]

Hi! For reasons of cross-platform compatibility, bit7z v4.0 uses std::fstream internally for reading and writing files. This may explain why you noticed some overhead, as C++ file streams are notoriously slow. On the other hand, bit7z v3 used part of 7-Zip's source code for the internal file streams, which used low level I/O functions, and thus without std::fstream's overhead. On the develop branch (the future bit7z v4.1, still work-in-progress, but close to beta), I have completely rewritten bit7z's file streams from scratch to use the low-level I/O functions provided by the OS instead of std::fstream. In my tests, the overhead has been significantly reduced, to the point that the performance is now really close to that of bit7z v3/7-Zip. However, I might have missed some test cases. If you'd like to, you can try testing the develop branch and see if it improves performance for your use cases.

This might explain why v4 is about 10% slower than v3 on machines 1, 2, and 3 . But how can explain that v4 on machines 4, 5, and 6 is several times slower?

[wwvv1235]

This is supplementary information for CPU monitoring during the decompression process.
machines 1, 2, 3:

machines 4, 5 ,6:

It appears that no concurrency was achieved on machine 4, 5 ,6.

I tried adding log output to 7z source code MtDec.c, recompiled 7zxa.dll, and compared the output information between v4 and v3.
The code to add output log is as follows

The log results output on machine 4, 5 ,6 are compared as follows:

The results show that the waiting time for V4 is more than 10 times longer than that for V3.

[rikyoz]

That's really strange, indeed.

This might explain why v4 is about 10% slower than v3 on machines 1, 2, and 3 . But how can explain that v4 on machines 4, 5, and 6 is several times slower?

It probably doesn't explain it, but in my experience I've noticed a wide range of results in terms of the overhead of v4 compared to v3/v4.1.

Besides the file streams, the main sources of overhead in bit7z are:

• Callbacks

  • 7-Zip blocks the current operation while executing it, so callbacks must either run quickly or perform an asynchronous operation to avoid adding overhead

• String conversion

  • By default, bit7z uses std::string in its API, but it needs to convert them to std::wstring to correctly support Unicode on Windows;
  • This conversion may introduce overhead, particularly if there are many files in the archive and thus many string encoding conversions.
  • You could try using the BIT7Z_USE_NATIVE_STRING option in v4 to avoid such overhead.

However, the code you provided does not use callbacks, and in my experience, the overhead caused by string conversion is usually negligible.

The only way to be sure that, by chance, v4.1 already fixes your issue is to test it.

Could you share the input test file with me, or at least provide some information about the type of files it includes (e.g. whether they are binary or text files, and their respective sizes), and the settings you used to create it (e.g. whether it is a solid archive or not)?
In any case, I'll try to replicate the issue.

Also, I noticed that all the affected machines satisfy a 'condition 02'. What does this mean?

Thank you in advance!

[wwvv1235]

That's really strange, indeed.

This might explain why v4 is about 10% slower than v3 on machines 1, 2, and 3 . But how can explain that v4 on machines 4, 5, and 6 is several times slower?

It probably doesn't explain it, but in my experience I've noticed a wide range of results in terms of the overhead of v4 compared to v3/v4.1.

Besides the file streams, the main sources of overhead in bit7z are:

* Callbacks
  
  * 7-Zip blocks the current operation while executing it, so callbacks must either run quickly or perform an asynchronous operation to avoid adding overhead

* String conversion
  
  * By default, bit7z uses std::string in its API, but it needs to convert them to std::wstring to correctly support Unicode on Windows;
  * This conversion may introduce overhead, particularly if there are many files in the archive and thus many string encoding conversions.
  * You could try using the BIT7Z_USE_NATIVE_STRING option in v4 to avoid such overhead.

However, the code you provided does not use callbacks, and in my experience, the overhead caused by string conversion is usually negligible.

The only way to be sure that, by chance, v4.1 already fixes your issue is to test it.

Could you share the input test file with me, or at least provide some information about the type of files it includes (e.g. whether they are binary or text files, and their respective sizes), and the settings you used to create it (e.g. whether it is a solid archive or not)? In any case, I'll try to replicate the issue.

Also, I noticed that all the affected machines satisfy a 'condition 02'. What does this mean?

Thank you in advance!

Thank you for your answer.
The 'condition 02' is that those machines run a large number of test scripts daily,but no test scripts are run during the test decompression process.These scripts write some files to the temporary directory on the C drive; we're unsure if this will have any impact.
Condition 1 and Condition 2 are the most obvious differences between machines 01, 02, 03 and machines 04, 05, 06.
This is the input test file address : https://drive.google.com/file/d/1t4OKzamTcssZK-jGzLkhNUcCFje9NG5a/view?usp=sharing.
I'll also tried testing it with version 4.1.

[rikyoz]

The 'condition 02' is that those machines run a large number of test scripts daily,but no test scripts are run during the test decompression process.These scripts write some files to the temporary directory on the C drive; we're unsure if this will have any impact.

I'm unsure as well, but I would say they shouldn't have any impact.

This is the input test file address : https://drive.google.com/file/d/1t4OKzamTcssZK-jGzLkhNUcCFje9NG5a/view?usp=sharing.

Perfect, thanks for the test file!
Over the last few days, I have managed to run some benchmarks using the test file you provided.
The benchmarks ran the extraction 100 times, with a "cooldown" 10s period between each run.
All the tests were ran in the same conditions in a VM.
I tested bit7z v3, v4, and v4.1. I also tested v4.x with and without the option BIT7Z_USE_NATIVE_STRING, which can reduce the overhead (as I already mentioned).
These are the results of the benchmarks as box plots:

In my tests, v4.0 performed significantly worse than v3 and v4.1, with a higher average, wider variance of results, and lots of outliers.

Without the outliers, you can better see the range of values obtained by each version of bit7z:

I also created a boxplot excluding the v4.0 results, but including outliers:

In my tests, the results for v4.1 were within the same range as those for v3, but with better variance (they were all closer to the average, whereas the results for v3 were more spread out).
Furthermore, v4.1 with native strings performed better on average than v3.
In other words, v4.1 performs on par with v3, if not better, at least in my benchmarks.

I'll also tried testing it with version 4.1.

Let me know if you get better results with v4.1

Thank you again for the test file! 🙏

[wwvv1235]

Let me know if you get better results with v4.1

Thank you for your test data.
Here is the test data I obtained using v4.1 on my machines.

Based on the test results, v4.1 does show improved performance compared to v4.0.10, but it is still significantly slower than v3.1.5 on our machines 4, 5, and 6.

[rikyoz]

That's really strange!

Thank you for testing v4.1, on machine 1 to 3 seems even faster than v3.

I'll run some more benchmarks on a PC with different hardware to try and replicate the issue.

It does seem to be a problem related to condition 2, for some reasons.
Some profiling will probably be necessary.

[wwvv1235]

That's really strange!

Thank you for testing v4.1, on machine 1 to 3 seems even faster than v3.

I'll run some more benchmarks on a PC with different hardware to try and replicate the issue.

It does seem to be a problem related to condition 2, for some reasons. Some profiling will probably be necessary.

Thank you very much for the detailed and thoughtful explanation.

I really appreciate the time and effort you put into testing and analyzing this. Hopefully you’ll be able to reproduce the issue on another machine, which should make it easier to track down the root cause.

I’m also looking forward to a fix once the problem is better understood.
Thanks again for the careful investigation and the clear communication.

😊