Poor compression of >20GB exe/msi/cab sample
-
@diskzip using forced settings on 7z.dll doesnt work well, it will apply them to all files and worsen compression for everything. Unless you select settings for each file separately. So it is not a solution except for hand picked sample.
So what setting did you use on archive you sent, I am pretty sure it was created by 7z.exe and not diskzip? You can see it by type of filters used.
As to the zipx, it has significantly worse compression for anything (not to mention mt1 or mt2 in mI ost cases) but jpeg and wav, so so again users would have to compress files separately and hand pick which go into zipx and which goes into 7z.
With Pa, we added extension sort in latest version and you can use 2g window, so result is 2645, it is easily repeatable…
We filter all these files automatically and apply over 15 different codecs and filters, so generally it will produce better results in most real life cases than using different format for each file. Realistically you cant compare that to using 7z dll with bcj2 on all files. For people using 7z format, best bet is to use 7z.exe and not 3Rd party tools due yo the file detection that 7z.exe uses, your result will never be as good.
-
@spwolf said in Poor compression support:
@diskzip using forced settings on 7z.dll doesnt work well, it will apply them to all files and worsen compression for everything. Unless you select settings for each file separately. So it is not a solution except for hand picked sample.
So what setting did you use on archive you sent, I am pretty sure it was created by 7z.exe and not diskzip? You can see it by type of filters used.
As to the zipx, it has significantly worse compression for anything (not to mention mt1 or mt2 in mI ost cases) but jpeg and wav, so so again users would have to compress files separately and hand pick which go into zipx and which goes into 7z.
With Pa, we added extension sort in latest version and you can use 2g window, so result is 2645, it is easily repeatable…
We filter all these files automatically and apply over 15 different codecs and filters, so generally it will produce better results in most real life cases than using different format for each file. Realistically you cant compare that to using 7z dll with bcj2 on all files. For people using 7z format, best bet is to use 7z.exe and not 3Rd party tools due yo the file detection that 7z.exe uses, your result will never be as good.
No.
First, as I’ve mentioned before, DiskZIP is not based on 7z.exe or 7z.dll. We have our own proprietary wrapper around the 7-Zip code, probably similar to how PA does it - with the major difference that we do not actually change any compression code. The advantage of this approach is that we do enjoy all features that are inside 7-Zip as a “first class citizen” of the 7-Zip stack.
This includes, again as I have mentioned before, proper file sorting, automatic filter application, among others.
This is probably why you’re adamant the file I sent you must have been created using 7z.exe (or 7z.dll) instead of DiskZIP. If you still have any doubts, please pick the first command line override parameter (which configures for the highest compression) and reproduce the results for yourself. This will of course require a whole lot of memory, which is why we don’t include this setting by default in any of our out-of-the-box compression profiles.
As for your specific points:
Extension sort in DiskZIP is standard in all compression profiles, but can be turned off if the user so desires (just set File Sorting to false). This was actually a surprising regression in 7-Zip compression performance between the latest branches 16.x-17.x and the earlier 9.2x branches. Fortunately, we never passed this regression on to our customers.
Correct filter application is, again, automatic with the overridden command line - of course, if you use the GUI settings, the default profiles do lock you in to BCJ2, but you can change them to whatever you want (and it would be hardly unexpected to get the filter you configured at that point).
It would still have been nice had you been able to test our ZIPX format. Maybe the results would have surprised you?
Last but not least, the reason we did choose the BCJ2 filters as default in our profiles was because they performed best in our tests for all samples we came across, not just cherry-picked test cases. Of course, it is understandable that our median test cases and your median test cases would differ.
I hope that helps clear some of the confusion. At the end of the day, is PA still unable to meet or exceed DiskZIP’s compression on our sample data set (which is, again, a typical load for our environment, and not a hand-picked specially crafted set designed just to defeat PA - that would be quite hard to manually build, I’m sure!)
-
@diskzip again, your file that you provided seems to be created with 7z.exe. File created by DiskZip does not have these filters used and has 150 MB larger size. There is no special switch in 7zip to make it use itanium filter for instance, it is part of bcj2 and used when 7z.exe detects appropriate executable. When you use 7z.exe to create your folder, it will automatically apply itanium filter when it detects such executable.
Same goes for the use of multimedia delta filter. Diskzip does not use delta filters at all as it needs 7z.exe to determine what file to use it on. As such, DiskZip will always create different/worse results compared to 7zip.
Please let me know what switch to use in order to replicate file you have sent as example of DiskZip compression.
As to “your” zipx compression, it is actually WinZip Zipx compression. You are aware that zipx is not solid compression and that it creates significantly larger files than 7z? When it comes to special codecs - PA format has better codecs for text, jpeg, mp3 compared to WinZip zipx (specifically whats unique compared to WinRar and 7zip) together with everything else that makes PA format unique. It is considerably faster while having considerably better compression at the same time.
So yeah, we try WinZips zipx every time we add new codec to PA format and benchmark it against it, as well as 7zip, WinRAR, FreeArc as well as speciality compressors like precomp. Obviously we try to do something better, even if we do not succeed each time.
And since you obviously consider diskzip to be on par with other compression applications, why not submit it for testing at:
http://www.squeezechart.com/That way you will have independent tests to back up those claims of first class citizen. Problem is that in tests that I do with DiskZip, it creates larger files than 7zip but I would love to be proven wrong. I am sure @Stephan will be helpful as usual.
-
Thank you for sticking around, we’ll get to them bottom of this.
Please see the step-by-step instructions I’ve posted here for configuring the compression string manually:
https://encode.ru/threads/130-PowerArchiver?p=53664&viewfull=1#post53664
It is easier to attach images to a post there, so please excuse me for having to redirect you there for instructions. There are precise instructions there though, so your detour is worth it.
For ZIPX, we use the BricolSoft Zip ActiveX control - this excellent library may be worth for you folks to check out as well. After all, nobody on this thread invented 7-Zip, and nobody here invented ZIPX either!
-
@diskzip said in Poor compression support:
https://encode.ru/threads/130-PowerArchiver?p=53664&viewfull=1#post53664
cool, will test it out with that setting sometimes soon.
-
We have just released DiskZIP 2018, with the following enhancements:
https://encode.ru/threads/2763-DiskZIP
Thank you very much for the feedback you provided on this thread regarding the usage of CPU cores. This issue is now addressed by way of utilizing all available CPU cores (with the exception of the highest compression profiles, which limit to two CPU cores in order to ensure the best compression ratios).
Please also note, you would now need to choose the second command line override string instead of the first, because in DiskZIP 2018, the first command line override string again forces BCJ2 compression :)
I know, ironic! The customer is always right, and that’s what they wanted…
So please excuse the inconvenience caused by the inaccurate instructions - as you will see for yourself when you take a look at the custom compression strings though, the second one does engage 7-Zip’s automatic file detection filters.
I would like to thank you all once again, on behalf of the entire DiskZIP team, for your feedback - and we look forward to any further feedback you may have on the 2018 release. Wishing you all a great weekend!
-
@diskzip now we get PR releases on our forums, do you have a link to it so i can delete the huge post relevant mostly to your product?
-
@spwolf You are right, please excuse my enthusiasm. I have made the edit directly, please don’t hesitate to let me know if it is not satisfactory.
-
@spwolf Have you had a chance to test our native compression yet? Please note, as I described in my new release announcement post, to use an auto-switching filter, you now how to use the second command line override parameter (instead of the first as it was in the prior version). Thanks!
-
@diskzip whats native compression, 7z?
Did not have a chance to try new version yet, i might this week.
As to the PA format, our current record with simple/optimized setting is:
PA 17.01.03: 2,460,182 kB (d2G, mt1)
7zip max settings: 2,593,514 kB
Your sample: 2,600,325 kBWe adjusted extension groupings, added more extensions to the exe/dll group that our exe filters are applied to and added unlimited size blocks to get better compression on samples over 10GB.
I think we can do at least 20-30M better with current settings, not everything is still perfectly grouped together for this sample.
So currently around 130M better than best 7z settings, 136M better than dzip.
-
@spwolf said in Poor compression support:
@diskzip whats native compression, 7z?
Did not have a chance to try new version yet, i might this week.
As to the PA format, our current record with simple/optimized setting is:
PA 17.01.03: 2,460,182 kB (d2G, mt1)
7zip max settings: 2,593,514 kB
Your sample: 2,600,325 kBWe adjusted extension groupings, added more extensions to the exe/dll group that our exe filters are applied to and added unlimited size blocks to get better compression on samples over 10GB.
I think we can do at least 20-30M better with current settings, not everything is still perfectly grouped together for this sample.
So currently around 130M better than best 7z settings, 136M better than dzip.
By native compression, I was asking whether you were able to reproduce our results on our testing data set using DiskZIP and the updated compression string for the 7ZIP file type, natively inside DiskZIP, without using 7z.exe or 7z.dll or any other external process.
So can you share a compression string - or other instructions to configure PA - so that I may be able to reproduce your results internally?
Also, glad to see you were able to push 7-Zip 6 MB more than the built-in DiskZIP. What compression string did you use to achieve this - or what version of 7-Zip?
We should be able to replicate the exact same result in DiskZIP, of course; its just a matter of discovering the compression string.
Thanks again, and congratulations!
-
@diskzip yes, i was… when it comes to 7z, I just maximized settings in 7z gui and added same switches you use for sorting, and that gave me 6-7 MB smaller file. Try it out and see what are the differences between your internal switches.
There is no overly complicated string or anything like that in PA, just select 2000 for dictionary and mt1, extreme setting of course. Same as before.
Update should be out today or tomorrow, depending on QA team testing, there quite a number of things changed for other parts of PA. Update from last month already got the same settings down to 2.599… There is no change in codecs.
We should get few mb more at least in the end. It was useful for us as a testing in the end, to add more exe/dlls formats on the list, as well as sorting/big block switch for files over 10G total.
-
Of course. Glad I could help :)
-
New record with Razor: 2,413,444 kB
https://encode.ru/threads/130-PowerArchiver?p=54599&viewfull=1#post54599 -
@nikkho said in Poor compression of >20GB exe/msi/cab sample:
New record with Razor: 2,413,444 kB
https://encode.ru/threads/130-PowerArchiver?p=54599&viewfull=1#post54599Yes, while we have been bickering here about DLLs and EXEs vs native implementations; someone has actually improved something :)