<Z=7 >  c " r>J  Xp[O??u;u!y"c$"j$r%B'C() *Y+    Compression I specifies the method to analyze the data produced by the match finder. Supported I are B and B. The default is B for I 0-3 and B for I 4-9.Currently only simple byte-wise delta calculation is supported. It can be useful when compressing e.g. uncompressed bitmap images or uncompressed PCM audio. However, special purpose algorithms may give significantly better results than Delta + LZMA2. This is true especially with audio, which compresses faster and better e.g. with B(1).Currently the only threading method is to split the input into blocks and compress them independently from each other. The default block size depends on the compression level and can be overridden with the B<--block-size=>I option.DictSize is the LZMA2 dictionary size. It is waste of memory to use a dictionary bigger than the size of the uncompressed file. This is why it is good to avoid using the presets B<-7> ... B<-9> when there's no real need for them. At B<-6> and lower, the amount of memory wasted is usually low enough to not matter.Dictionary (history buffer) I indicates how many bytes of the recently processed uncompressed data is kept in memory. The algorithm tries to find repeating byte sequences (matches) in the uncompressed data, and replace them with references to the data currently in the dictionary. The bigger the dictionary, the higher is the chance to find a match. Thus, increasing dictionary I usually improves compression ratio, but a dictionary bigger than the uncompressed file is waste of memory.Even though the assumed alignment can be adjusted with I and I, LZMA1 and LZMA2 still slightly favor 16-byte alignment. It might be worth taking into account when designing file formats that are likely to be often compressed with LZMA1 or LZMA2.In multi-threaded mode about three times I bytes will be allocated in each thread for buffering input and output. The default I is three times the LZMA2 dictionary size or 1 MiB, whichever is more. Typically a good value is 2-4 times the size of the LZMA2 dictionary or at least 1 MiB. Using I less than the LZMA2 dictionary size is waste of RAM because then the LZMA2 dictionary buffer will never get fully used. The sizes of the blocks are stored in the block headers, which a future version of B will use for multi-threaded decompression.In multi-threaded mode the sizes of the blocks are stored in the block headers. This isn't done in single-threaded mode, so the encoded output won't be identical to that of the multi-threaded mode.In single-threaded mode no block splitting is done by default. Setting this option doesn't affect memory usage. No size information is stored in block headers, thus files created in single-threaded mode won't be identical to files created in multi-threaded mode. The lack of size information also means that a future version of B won't be able decompress the files in multi-threaded mode.On GNU and *BSD, B(1) and B(1) can be used to parallelize compression of many files:Reasonable I for Hash Chains is 4-100 and 16-1000 for Binary Trees. Using very high values for I can make the encoder extremely slow with some files. Avoid setting the I over 1000 unless you are prepared to interrupt the compression in case it is taking far too long.The uncompressed size of the file can be stored in the B<.lzma> header. LZMA Utils does that when compressing regular files. The alternative is to mark that uncompressed size is unknown and use end-of-payload marker to indicate where the decompressor should stop. LZMA Utils uses this method when uncompressed size isn't known, which is the case for example in pipes.These BCJ filters are very fast and use insignificant amount of memory. If a BCJ filter improves compression ratio of a file, it can improve decompression speed at the same time. This is because, on the same hardware, the decompression speed of LZMA2 is roughly a fixed number of bytes of compressed data per second.To reduce the size of the executable, B doesn't support multithreading or localization, and doesn't read options from B and B environment variables. B doesn't support displaying intermediate progress information: sending B to B does nothing, but sending B terminates the process instead of displaying progress information.To use a pager other than the default B set environment variable B to the name of the desired program. The name B is provided for backward compatibility with LZMA Utils.User-specific or system-wide default options. Typically this is set in a shell initialization script to enable B's memory usage limiter by default. Excluding shell initialization scripts and similar special cases, scripts must never set or unset B.When the aligment is known, setting I accordingly may reduce the file size a little. E.g. with text files having one-byte alignment (US-ASCII, ISO-8859-*, UTF-8), setting B can improve compression slightly. For UTF-16 text, B is a good choice. If the alignment is an odd number like 3 bytes, B might be the best choice.Project-Id-Version: xz-utils Report-Msgid-Bugs-To: FULL NAME PO-Revision-Date: 2022-04-13 22:08+0000 Last-Translator: Anthony Harrington Language-Team: English (United Kingdom) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Launchpad-Export-Date: 2024-09-02 20:52+0000 X-Generator: Launchpad (build 1b1ed1ad2dbfc71ee62b5c5491c975135a771bf0) Compression I specifies the method to analyse the data produced by the match finder. Supported I are B and B. The default is B for I 0-3 and B for I 4-9.Currently, only simple byte-wise delta calculation is supported. It can be useful when compressing e.g. uncompressed bitmap images or uncompressed PCM audio. However, special purpose algorithms may give significantly better results than Delta + LZMA2. This is true especially with audio, which compresses faster and better e.g. with B(1).Currently, the only threading method is to split the input into blocks and compress them independently from each other. The default block size depends on the compression level and can be overridden with the B<--block-size=>I option.DictSize is the LZMA2 dictionary size. It is a waste of memory to use a dictionary bigger than the size of the uncompressed file. This is why it is good to avoid using the presets B<-7> ... B<-9> when there's no real need for them. At B<-6> and lower, the amount of memory wasted is usually low enough to not matter.Dictionary (history buffer) I indicates how many bytes are kept in memory of the recently processed uncompressed data. The algorithm tries to find repeating byte sequences (matches) in the uncompressed data, and replace them with references to the data currently in the dictionary. The bigger the dictionary, the greater the chance to find a match. Thus, increasing dictionary I usually improves compression ratio, but a dictionary bigger than the uncompressed file is waste of memory.Even though the assumed alignment can be adjusted with I and I, LZMA1 and LZMA2 still slightly favour 16-byte alignment. It might be worth taking into account when designing file formats that are likely to be often compressed with LZMA1 or LZMA2.In multi-threaded mode, about three times I bytes will be allocated in each thread for buffering input and output. The default I is three times the LZMA2 dictionary size or 1 MiB, whichever is more. Typically, a good value is 2-4 times the size of the LZMA2 dictionary or at least 1 MiB. Using I less than the LZMA2 dictionary size is a waste of RAM because then the LZMA2 dictionary buffer will never get fully used. The sizes of the blocks are stored in the block headers, which a future version of B will use for multi-threaded decompression.In multi-threaded mode, the sizes of the blocks are stored in the block headers. This isn't done in single-threaded mode, so the encoded output won't be identical to that of the multi-threaded mode.In single-threaded mode, no block splitting is done by default. Setting this option doesn't affect memory usage. No size information is stored in block headers, thus files created in single-threaded mode won't be identical to files created in multi-threaded mode. The lack of size information also means that a future version of B won't be able decompress the files in multi-threaded mode.On GNU and *BSD, B(1) and B(1) can be used to parallelise compression of many files:Reasonable I for Hash Chains is 4-100 and 16-1000 for Binary Trees. Using very high values for I can make the encoder extremely slow with some files. Avoid setting the I over 1000 unless you are prepared to interrupt the compression if it begins to take far too long.The uncompressed size of the file can be stored in the B<.lzma> header. LZMA Utils does that when compressing regular files. The alternative is to mark that uncompressed size is unknown and use end-of-payload marker to indicate where the decompressor should stop. LZMA Utils uses this method when uncompressed size isn't known, which is the case for example in pipes.These BCJ filters are very fast and use insignificant amount of memory. If a BCJ filter improves the compression ratio of a file, it can improve decompression speed at the same time. This is because, on the same hardware, the decompression speed of LZMA2 is roughly a fixed number of bytes of compressed data per second.To reduce the size of the executable, B doesn't support multithreading or localisation, and doesn't read options from B and B environment variables. B doesn't support displaying intermediate progress information: sending B to B does nothing, but sending B terminates the process instead of displaying progress information.To use a pager other than the default B, set environment variable B to the name of the desired program. The name B is provided for backward compatibility with LZMA Utils.User-specific or system-wide default options. Typically this is set in a shell initialisation script to enable B's memory usage limiter by default. Excluding shell initialisation scripts and similar special cases, scripts must never set or unset B.When the alignment is known, setting I accordingly may reduce the file size a little. E.g. with text files having one-byte alignment (US-ASCII, ISO-8859-*, UTF-8), setting B can improve compression slightly. For UTF-16 text, B is a good choice. If the alignment is an odd number like 3 bytes, B might be the best choice.