#Lzip vs rar archive#
#Lzip vs rar code#
#Lzip vs rar download#

#Lzip vs rar code#

Source code (and text in general) is typically highly compressible because of the amount of redundancy in the contents, but compressors like Gzip that operate with a much smaller dictionary don't get to take advantage of redundancy that goes beyond their dictionary size. tar.gz the uncompressed source code is about 542 MiB and is almost entirely text. As previously mentioned, Linux 3.7 source code is 67 MiB for. Why shuffle around extra data if you don't need to?ĭistributing large amounts of data that might be highly compressible. Assuming you'll be working with these backups on a modern desktop system with plenty of CPU power and the one-time-only compression speed isn't a serious problem, using XZ compression generally makes more sense. Copying this entire backup data set to a USB 2.0 hard drive (maxing out around 30 MiB/sec transfers) as Gzipped data would take 55 minutes, but XZ compression would make the backup take 20 minutes less.

tar.xz archives would cut a whopping 37.3 GiB off of the backup set. If the same compressibility exists in a data set you currently store as 100 GiB worth of.

#Lzip vs rar archive#

'xz -9e' yields an XZ archive that is 62.7% the size of the Gzip archive. Compressing the source code for Apache's httpd-2.4.2 with 'gzip-9' vs.

#Lzip vs rar download#

If you have a super fast connection, choosing XZ could mean saving one minute of download time on a cheap DSL connection or a 3G cellular connection, it could shave an hour or more off the download time. The Linux 3.7 kernel source code is 34 MiB smaller in XZ format than in Gzip format. Now, on the flip side, there are situations where XZ compression is vastly superior: doing the same thing I just described through an SSH tunnel over the Internet). I routinely shuffle folders quickly across a trusted LAN connection with commands such as 'tar -c * | lzop -1 | socat -u - tcp-connect:192.168.0.101:4444' and Gzip could be used similarly over a much slower link (i.e. Honestly, lzop is much faster than Gzip and still compresses okay, so applications that need the fastest compression possible and don't require Gzip's ubiquity should look at that instead. If compression time is more important than compression ratio, Gzip beats XZ. Compression is useless without the ability to decompress it. Gzip is pretty much universally supported by every UNIX-like system (and nearly every non-UNIX-like system too) created in the past two decades. Gzip compression is extremely fast on such processors when compared to all better compression methods such as XZ or even Bzip2. Three seconds extra to decompress on your Core i5 can be severely long on a 200 MHz ARM core or a 50 MHz microSPARC. Such systems usually have slow processors, and decompression time increases can be very high.

One might scoff at the thought of downloading and compiling the latest version of Bash on an ancient SparcStation LX with 32MB of RAM, but it happens. Gzip) off of a package destined for an OpenWrt router, what good is the minor space savings if the router has 16 MiB of RAM? A similar situation appears with very old computer systems. As an example, if XZ can shave 400 KiB (vs. Reasons why XZ is not necessarily as suitable as Gzip:Įmbedded and legacy systems are far more likely to lack sufficient available memory to decompress LZMA/LZMA2 archives such as XZ. The ultimate answer is accessibility, with a secondary answer of purpose.