Recent discussion reminded me of this languishing patch. The only reason to be wary is that it increases the decompression-time memory requirement to 48MiB (from 32MiB).
At least one very-small-system user complained back when I compressed some release tarball using -9: their system did not have sufficient RAM (64MiB) to decompress it. However, that was a few years ago, and this change adds only 16MiB, raising the requirement to 48MiB. Besides, in a pinch, such users can always decompress on another system and either operate directly on a recompressed (or uncompressed) tarball. What do you think? ----------------- * cfg.mk (XZ_OPT): Increase compression level to 9, yet with only 48MiB dictionary size (the default with -9 would have been 64MiB). This gets all but 1k worth of gain with only 16MiB additional decompression-time memory requirement over -8's default of 32MiB. Also, add pb=0. It is good for any US-ASCII, UTF-8, or ISO-8859-* text or other byte-aligned data. The default is pb=2 i.e. 2^2 = 4-byte alignment which seems to be the best compromise for unknown data. The result: decreases the size of the distributed .tar.xz file by 2.6% (aka 150KiB). While 49MiB would have yielded an addition 1KiB decrease, that would have resulted in encoding a dictionary size (in its 6-bit field) of 64MiB. Based on a suggestion and explanation from Lasse Collin. --- cfg.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cfg.mk b/cfg.mk index 7e28d9c..8a87c2a 100644 --- a/cfg.mk +++ b/cfg.mk @@ -46,7 +46,7 @@ export VERBOSE = yes # 5010604 9 # 4923016 8e # 4914152 9e -export XZ_OPT = -8e +export XZ_OPT = --lzma2=preset=9e,dict=48MiB,pb=0 old_NEWS_hash = 33e0d81904e66223883c8bc33c29a772 -- 2.9.3
