Closed AndrewBSzabo closed 1 year ago
I modified the code so that the passwords of the ZipEntry objects are used. I then will store encryption keys that have already been calculated in a dictionary (Dictionary<Password,EncryptionKey>) so that if the same password is used, we can just grab it from the dictionary rather than recalculating it again. With this change the performance improvement is now dependent on how many different passwords are being used when creating/adding to a zip. The following screenshot are some performance numbers when the number of passwords used in a file is varied from 1, 10, 100, and 1000:
We can see that we get the largest performance improvement when using <10 passwords, and the smallest performance improvement when using >1000 passwords (still some improvement, just not as much).
Fixed the build issue
All related unit tests are still passing, and I added a new WinZipAes test for creating a zip with entries that have different passwords.
Corrected this error and added two more unit tests. Let me know if there are any other issues. Thanks!
made those changes.
I left an issue about this (#271), but these changes will fix the issue.
These were the results I got from some performance testing:![image](https://user-images.githubusercontent.com/43353686/206538516-421a9053-4a4e-4e8c-8c4b-921e989e3ce3.png)
I tested with varying the encryption types (PKzipWeak vs WinZipAes256) with different compression types (Level9, Level4, and Level0) when compressing an 86.9MB folder with 2282 files. When using WinZipAes256 encryption (bottom 3 rows) we can see that after the performance changes made by this commit (last column) we saw ~85-73% (depending on the compression level) reduction in runtime compared to before the performance changes made by this commit (second last column).
If you need me to clean up the code at all before merging these changes, please let me know. Thanks!