Closed lr4d closed 2 years ago
The -T | --threshold
option was designed to take an optional argument to limit Threshold testing to N%. Somehow that feature did not make it to lrzip
. -T
alone (an argument is not tested for) will disable threshold testing totally. Not limit it. This feature is implemented in lrzip-next
. -T95
for example, would test the lz4 compression against 95% and if above, would not compress that block. Good practice to use it in general. The time saved is a better value than the compression benefit. See This wiki article on it
I removed the optional percentage a while ago. You're the first person to request it be implemented. The way it works now however, it aborts way too early to have any idea what the percentage will be by the end of the block; its point is to avoid compressing incompressible blocks entirely and your request is a pretty unique use case. It could be extended to do what you ask but I'm not currently implementing new features.
I've decided this isn't worth implementing, apologies.
When working with tarballs of media files and PDF's, lrzip sometimes gives me a fast 15% compression by just compressing 1/9 blocks e.g. truncated output of
lrzip -i -vv ...
:Other times, it takes a lot longer and struggles a lot more to compress:
In the latter case, I'd much rather prefer lrzip to not compress any blocks if the expected compression ratio for lz4 is <= 95 %, so as to get faster speed.
Using
lrzip --level=1
doesn't seem to make any difference in this regard.Is it feasible to make the threshold which lrzip uses for determining when the data is incompressible a cli parameter so I can set it manually?