7Zip incorrectly ASSUMES that it will not have enough RAM to complete a compression job and DOES NOT ALLOW IT to occur AT ALL instead of what it SHOULD do which is ALLOW the USER to CHOSE to continue ANYWAY (or a setting to ignore it completely).
This does NOT resolve the issue. You have built in a check to say "these settings will use this amount of ram, if this amount of ram isn't there, don't continue AT ALL.
No "memory usage" limit I tried let me continue ANYWAY as it SHOULD.
For Hyper-V with dynamic memory, and for operations who WONT actually USE that much RAM, its an ASSUMPTION that SHOULD NOT be a solid wall.
Again, see screenshots and file size listings for LITERAL PROOF that this is BROKEN and truly a BUG or even REGRESSION to functions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Try to change "Memory usage" option to "16384 GB" and then try your compressing operation.
7-Zip will remember that option for next compression operations.
Does it work for your case?
"Hyper-V" users are minor part from all 7-Zip users. So I included that new simple "memory usage" option for them to disable default limits.
And most of usual users will get some protection from system thrashing, if they select some dangerous option values that use more than available RAM size.
Last edit: Igor Pavlov 2021-11-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Igor, I don't think you are fully reading whats going on. We do NOT WANT to LIMIT the RAM USED, it results in LARGER archive size's OR (now) LONGER compression times!
Bug#1: You added a CRUDE ASSUMPTION calculation that says, "with these parameters, it WILL use X memory, CHECK memory capacity, if lower, DISPLAY ERROR AND STOP (it SHOULD NOT DO THIS), DESPITE the fact the operation WILL NOT USE EVEN CLOSE to the displayed memory REQUIRED (aka, its NOT REQUIRED, and is an ASSUMPTION and a WRONG one at that)
Bug #2: if you chose any % option, you get the error, or as I already informed you above, does not work
Bug #3: when I chose 16GB (the max it shows) out of my 32GB or 64GB on the system, then it loses out on using that extra memory thats there to complete the job with the best possible speed
The whole issue however, is with the ASSUMPTION being made of how much memory WILL be required, its totally and completely incorrect, the calculation is what COULD BE required in a WORSE CASE scenario, IE with my test sample with 21.04 modified to REMOVE this check, it topped out at 21.5GB of memory VS the ASSUMPTION shown which stated 300GB+ (and stopped me from even trying).
Now supposed you can fix bug #2 listed above so I can chose 90% of my memory, then for non Hyper-V usage, that SHOULD resolve the issue as file size on my one sample is the same (will have to retest using same files used in previous posting, not on that system right now).
EDIT: "And most of usual users will get some protection from system thrashing, if they select some dangerous option values that use more than available RAM size."
I missed this part, what "system thrashing" if I actually set out to compress and it DOES require more memory then I have, it just error's out, nothing "dangerous" about it.
Last edit: Hammerfest 2021-11-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Upper limit in that option is not 16 GB.
Upper limit is 16 TB.
If you set that option to max value - 16 TB, then new 7-Zip 19.05 works as old 7-Zip that had no limit checks.
7-Zip will not use all 16 TB. That option just allows you to disable limit checks.
So set "memory usage" to 16 TB and try same another options as you did with old 7-Zip.
System thrashing is virtual memory problem.
You can have 16 GB of RAM and 32 GB of virtual memory.
If 7-Zip will use 24 GB, it still can work with big swapping and system thrashing. It can be 1000 times slower for compression. And system can be in such state, that there is no any fast response to any user action. So it looks like system hanging.
And default limits can protect user from these "thrashing" states.
And you have the option to disable these limits with 16 TB option.
Last edit: Igor Pavlov 2021-11-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Does it only happen to me that on the File Manager, if I go to Help --> About 7-Zip... the File Manager locks up and I have to kill it via Task Manager?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It turned out to be at least somewhat related to DPI: I have two monitors each with different resolution/DPI. The about screen shows up on when 7zFM is on one screen, but shows offscreen on the other display, giving it the appearance that the application is locked up. Pressing Escape to close the about box works.
So the problem seems to be entirely about showing the about box on coordinates not visible on the current monitor. For what it's worth, this is on Windows 10 x64, 21H2.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks igor! are you going to release MSI installers or just EXE this time around?
EDIT: "other packages will be available later". should've read the thread.
Last edit: ilsambard 2021-11-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps my results are not accurate - I found errors in the work of the bundle "The motherboard - RAM." But without dash diagnostics (I suspect a partial malfunction VRM - there was a strong overheating and the radiator could not cope, but because the supply voltage sensor RAM always shows 1,502 V - 1,514 V, then the real voltage should be viewed on the card removed with the chassis that I can do only after the arrival of the replacement).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello. It's nice to see an official release even though v19.00 has been, and still is, fine for me.
I recently added .zipx assoc/ftype config to my 7-Zip install script and was surprised to not see it in the 7-Zip File Manager associations tab under "Options". I don't have a .zipx file currently to test with, but hoping support it still there and will be added to Options.
I'm another looking forward to the .msi installer. Does the .exe have any parameters other than /S (Silent) and /D (Output Directory)? Specifically, anything to do with file associations, restart options, and System/All User vs Current User installation options.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why didn't you add the -ssp switch option to the GUI version?
You have added the -ssp option which cannot be used in the context menu when creating an archive !!!
Not everyone uses 7z from the command line !!!
The new -ssp switch. If the switch -ssp is specified, 7-Zip doesn’t allow the system to modify “Last Access Time” property of source files for archiving and hashing operations.
Last edit: PiotrMP006 2021-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are two problems with such options in GUI:
1) GUI window is big enough already.
2) we need to update all 70+ language translations. It's not good, if almost all strings are translated and some strings are not translated in important window.
Maybe we could move that option to another window. Then it will be simpler for both these problems.
Last edit: Igor Pavlov 2021-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
7-Zip 21.05 was released.
Download
7-Zip for 64-bit Windows x64:
https://7-zip.org/a/7z2105-x64.exe
7-Zip for 32-bit Windows x86:
https://7-zip.org/a/7z2105.exe
7-Zip for 64-bit Windows ARM64:
https://7-zip.org/a/7z2105-arm64.exe
Another packages and source code will be available later.
What's new after 7-Zip 21.04 beta:
Last edit: Igor Pavlov 2021-11-21
Igor, could you also please share the source code for this release? Thanks!
"Another packages and source code will be available later."
9900K @ 5 GHz, RAM @ 4000 MHz
Last edit: Piotr Biesiada 2021-11-25
I don't like that there is big difference of results in 10 passes at the right panel log. Try to close all programs before benchmark and try again.
All programs were closed. Only 7-Zip GUI was open.
Congrats for the release, almost 3 years in the making, btw, it'd be nice to have full changelog here. ;)
Igor thanks for your program!
I saw compression degradation (~3.6kb) after 21.03, when create self extraction archive.
Last edit: xake77 2021-11-21
It's because of sfx-exe stub is 3.6 KB larger in 21.05.
The compression ratio was not changed.
Simple benckmark use 7zFM v21.04 and v21.05 - screenshots. Host system:
CPU Xeon E5-2697v2 (12 core, 24 threads, 2,7 GHz, L3 30 Mb)
m/b QUIDA X79-P3 (know as Jingsha X79P3) chipset C602J
RAM 64 Gb 4 pcs Samsung M393B2G70QH0-CMA (REG ECC DDR3-1866 13.0-13-13-32 Cr1, 16 GB)
Video GTX 1660
OS Win7 SP1 x64
As already reported in .04, and also in .03
7Zip incorrectly ASSUMES that it will not have enough RAM to complete a compression job and DOES NOT ALLOW IT to occur AT ALL instead of what it SHOULD do which is ALLOW the USER to CHOSE to continue ANYWAY (or a setting to ignore it completely).
https://sourceforge.net/p/sevenzip/discussion/45797/thread/ba29828ce0/#3c6c
This results in larger archives making 7Zip create larger archives then the competition and longer compression times.
Now you can change that "Memory usage" limit in new combo box.
This does NOT resolve the issue. You have built in a check to say "these settings will use this amount of ram, if this amount of ram isn't there, don't continue AT ALL.
No "memory usage" limit I tried let me continue ANYWAY as it SHOULD.
For Hyper-V with dynamic memory, and for operations who WONT actually USE that much RAM, its an ASSUMPTION that SHOULD NOT be a solid wall.
Again, see screenshots and file size listings for LITERAL PROOF that this is BROKEN and truly a BUG or even REGRESSION to functions.
Try to change "Memory usage" option to "16384 GB" and then try your compressing operation.
7-Zip will remember that option for next compression operations.
Does it work for your case?
"Hyper-V" users are minor part from all 7-Zip users. So I included that new simple "memory usage" option for them to disable default limits.
And most of usual users will get some protection from system thrashing, if they select some dangerous option values that use more than available RAM size.
Last edit: Igor Pavlov 2021-11-21
Igor, I don't think you are fully reading whats going on. We do NOT WANT to LIMIT the RAM USED, it results in LARGER archive size's OR (now) LONGER compression times!
Bug#1: You added a CRUDE ASSUMPTION calculation that says, "with these parameters, it WILL use X memory, CHECK memory capacity, if lower, DISPLAY ERROR AND STOP (it SHOULD NOT DO THIS), DESPITE the fact the operation WILL NOT USE EVEN CLOSE to the displayed memory REQUIRED (aka, its NOT REQUIRED, and is an ASSUMPTION and a WRONG one at that)
Bug #2: if you chose any % option, you get the error, or as I already informed you above, does not work
Bug #3: when I chose 16GB (the max it shows) out of my 32GB or 64GB on the system, then it loses out on using that extra memory thats there to complete the job with the best possible speed
The whole issue however, is with the ASSUMPTION being made of how much memory WILL be required, its totally and completely incorrect, the calculation is what COULD BE required in a WORSE CASE scenario, IE with my test sample with 21.04 modified to REMOVE this check, it topped out at 21.5GB of memory VS the ASSUMPTION shown which stated 300GB+ (and stopped me from even trying).
Now supposed you can fix bug #2 listed above so I can chose 90% of my memory, then for non Hyper-V usage, that SHOULD resolve the issue as file size on my one sample is the same (will have to retest using same files used in previous posting, not on that system right now).
EDIT: "And most of usual users will get some protection from system thrashing, if they select some dangerous option values that use more than available RAM size."
I missed this part, what "system thrashing" if I actually set out to compress and it DOES require more memory then I have, it just error's out, nothing "dangerous" about it.
Last edit: Hammerfest 2021-11-21
Upper limit in that option is not 16 GB.
Upper limit is 16 TB.
If you set that option to max value - 16 TB, then new 7-Zip 19.05 works as old 7-Zip that had no limit checks.
7-Zip will not use all 16 TB. That option just allows you to disable limit checks.
So set "memory usage" to 16 TB and try same another options as you did with old 7-Zip.
System thrashing is virtual memory problem.
You can have 16 GB of RAM and 32 GB of virtual memory.
If 7-Zip will use 24 GB, it still can work with big swapping and system thrashing. It can be 1000 times slower for compression. And system can be in such state, that there is no any fast response to any user action. So it looks like system hanging.
And default limits can protect user from these "thrashing" states.
And you have the option to disable these limits with 16 TB option.
Last edit: Igor Pavlov 2021-11-21
Does it only happen to me that on the File Manager, if I go to Help --> About 7-Zip... the File Manager locks up and I have to kill it via Task Manager?
Check it again.
Is it x64 version of 7-zip?
What version of Windows?
It turned out to be at least somewhat related to DPI: I have two monitors each with different resolution/DPI. The about screen shows up on when 7zFM is on one screen, but shows offscreen on the other display, giving it the appearance that the application is locked up. Pressing Escape to close the about box works.
So the problem seems to be entirely about showing the about box on coordinates not visible on the current monitor. For what it's worth, this is on Windows 10 x64, 21H2.
thanks igor! are you going to release MSI installers or just EXE this time around?
EDIT: "other packages will be available later". should've read the thread.
Last edit: ilsambard 2021-11-22
Perhaps my results are not accurate - I found errors in the work of the bundle "The motherboard - RAM." But without dash diagnostics (I suspect a partial malfunction VRM - there was a strong overheating and the radiator could not cope, but because the supply voltage sensor RAM always shows 1,502 V - 1,514 V, then the real voltage should be viewed on the card removed with the chassis that I can do only after the arrival of the replacement).
we can hope for an installation format soon, .*.msi
Hello. It's nice to see an official release even though v19.00 has been, and still is, fine for me.
I recently added .zipx assoc/ftype config to my 7-Zip install script and was surprised to not see it in the 7-Zip File Manager associations tab under "Options". I don't have a .zipx file currently to test with, but hoping support it still there and will be added to Options.
I'm another looking forward to the .msi installer. Does the .exe have any parameters other than /S (Silent) and /D (Output Directory)? Specifically, anything to do with file associations, restart options, and System/All User vs Current User installation options.
Thank you.
Why didn't you add the -ssp switch option to the GUI version?
You have added the -ssp option which cannot be used in the context menu when creating an archive !!!
Not everyone uses 7z from the command line !!!
Last edit: PiotrMP006 2021-11-24
There are two problems with such options in GUI:
1) GUI window is big enough already.
2) we need to update all 70+ language translations. It's not good, if almost all strings are translated and some strings are not translated in important window.
Maybe we could move that option to another window. Then it will be simpler for both these problems.
Last edit: Igor Pavlov 2021-11-24