You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using pxz to backup large databases. The resulting xz file needs to be fully scanned by 7zip to be able to give basic info like compression rate and original filesize. xz -l also takes a very long time on huge files created by pxz. The same huge file (40GB xz file) can be opened instantaneous when compressed by xz itself, whether single threaded with 5.1 or multithreaded with xz 5.2
Based on this data I assume that having multiple streams result in full file scan when opening the files or retrieving info. It would be great if this could be fixed in pxz. Since development seems to be halted I would advise people to use the new xz 5.2.
The text was updated successfully, but these errors were encountered:
I am using pxz to backup large databases. The resulting xz file needs to be fully scanned by 7zip to be able to give basic info like compression rate and original filesize. xz -l also takes a very long time on huge files created by pxz. The same huge file (40GB xz file) can be opened instantaneous when compressed by xz itself, whether single threaded with 5.1 or multithreaded with xz 5.2
Difference in output of xz -l (example data)
xz, single threaded compression:
pxz, multithreaded compression:
xz 5.2 (multithreaded) compression:
Based on this data I assume that having multiple streams result in full file scan when opening the files or retrieving info. It would be great if this could be fixed in pxz. Since development seems to be halted I would advise people to use the new xz 5.2.
The text was updated successfully, but these errors were encountered: