11 ms·
bzip3
- kosolam 9d agoImpressive compression benchmark. Four times smaller than z standard.
- dist-epoch 9d agowith zstd at level 16 with default params (dict size, ...). Serious compression starts at level 19 and with much higher dict sizes. how is this an honest benchmark: bzip3 ... 12178M memory zstd ... 687M memory
- myrmidon 9d agoThere is a comparison with "zstd -19" on the Silesia corpus, showing better compression ratio for bzip3 (47.2 vs 53MB) while being ~5 times faster (and using only half the memory). Even if the examples are highly cherry-picked, it is quite suprising to me that such pareto-dominance is possible at all. edit: Tested it myself and found that it often also does slightly worse than zstd -19 in compression ratio but faster (it was slower in one case on "uncompressible" input). Compression performance vs "zstd -19" seems to depends a lot on actual input data in a very unpredictable way. I'd assume the benchmarks that they show are definitely somewhat cherry-picked.
- dist-epoch 9d agohaving used zstd, it has terrible defaults, optimized for speed and low-memory. You need to change it's params (not just level and dict size) to get high performance. probably somebody should use a coding agent to do auto-research to optimize params for each compression algo, while matching one fixed goal - time, memory or size
- adrian_b 9d agoI have not experimented with bzip3 recently, but more than a year ago I have done many tests with it. Initially I was extremely impressed with it, because in a lot of tests it succeeded to compress hard-to-compress files, like movies, and in many cases it demonstrated a much better compromise between speed and compression ratio than zstd, i.e. depending on the command parameters I could make it either compress better than zstd at similar compression/decompression speed, or compress/decompress faster at a similar compression ratio. Alas, the initial extremely favorable conclusion was short-lived, because trying later bzip3 on other data files gave worse results than zstd. So the final conclusion was that the performance of bzip3 was somewhat unpredictable, being highly data dependent. For some files it provided outstanding compression ratio or speed, but for others it was inferior. The problem was that without doing a compression there was no way to guess whether a file would be among those preferred by bzip3 or by zstd or by xz. So now I would use it only for a file for which I want maximum compression and which I would compress once and decompress many times, so I can afford a very long compression time, during which I would test multiple compression algorithms, including bzip3 and zstd, with multiple parameter choices, and I would eventually choose the one that offers the best compromise between compression ratio and decompression time, for that particular file. It certainly is a competitive compression algorithm, but unless it has changed since I last tested it, you cannot guess for which files it would win the compression competition.
- m000 9d agoWould a multi-stream archive format make sense at this point? I.e. store several compressed streams in the same file and use heuristics to decide where each file (or portion of file) goes.
- adrian_b 9d agoI think so. But developing the heuristics for choosing the appropriate compression algorithm for a stream of data is likely to need a very long time for compression tests of a lot of diverse training data, similarly to the training of a specialized ML model that classifies patterns. Such heuristics should provide not only algorithm selection, but also parameter selection, when given only some simple input, e.g. the relative importances of compression ratio, decompression speed and compression speed.
- eis 9d agoThe benchmark is very rudimentary. It does not test different levels/settings apart from its own -b 256/512 (does it affect decompression?), it doesn't measure compression time and memory usage. It does not specify parallel vs single-threaded (it mentions parallel on the one decoding number but what about the others?). The lrzip test is interesting but it omits for example zstd and doesn't even have (de-)compression timings. A lot more numbers are needed to present a fair and informative comparison. I don't want this to be a swipe against bzip3, I only want to point out the presented benchmarks could be a lot better.
- sylware 9d agoIsn't that XZ?
- adrian_b 9d agoNo. It is an unrelated algorithm.
- vintermann 9d agoIt's a very strange algorithm completely different from most compression methods, that's what makes it interesting IMO. But it's probably not realistically competitive, since one needs to do more after the burrows-wheeler transform, and all that "more" has been ridiculously more optimized in zstd and other modern compression methods. Compressing bwt-transformed data is easier, but that doesn't mean it's easy to further than what's easy.
- sylware 8d agoI saw bellard neural net compression benchmarks. If you have time and performant system, based on the semantic of the data to compress, neural net seems tough to beat. It is a matter of good compromises: speed and efficacy. I even wonder if LZMA2 is worth replacing bzip2.
- BoingBoomTschak 9d agoYou're probably thinking of LZMA2.
- altairprime 9d agoPreviously: “Hi, tool author here.” A useful explanation of Burrows-Wheelers transform as used by bzip3: https://news.ycombinator.com/item?id=42902407 https://news.ycombinator.com/item?id=42902407 “bzip3 is not yet listed on the large text compression benchmark” It is now: https://mattmahoney.net/dc/text.html https://mattmahoney.net/dc/text.html (2 years ago, 176 comments) https://news.ycombinator.com/item?id=42899713 https://news.ycombinator.com/item?id=42899713 (4 years ago, 104 comments) https://news.ycombinator.com/item?id=31324439 https://news.ycombinator.com/item?id=31324439
- p-e-w 9d ago> “Hi, tool author here.” A useful explanation of Burrows-Wheelers transform as used by bzip3 FWIW, the Burrows-Wheelers transform is also used by bzip2, so this isn’t a new feature even though that quote kinda sounds like it is.
- altairprime 9d agoIt’s also used in this paper blending an aspect of LZ77 with BWT: https://arxiv.org/abs/1502.05937 https://arxiv.org/abs/1502.05937 https://github.com/nicolaprezza/lz-rlbwt https://github.com/nicolaprezza/lz-rlbwt Which leads me to wonder if someone did, in fact, solve how to ‘combine zstd and bzip’ (so to speak) since the last time.
- mitxela 9d agoThey missed an opportunity to call it the Wheel-Burrow algorithm didn't they
- andruby 9d ago> “bzip3 is not yet listed on the large text compression benchmark” It is now And it comes in relatively well, in my opinion. I'm a compression amateur, but bzip3 is the first entry I recognize as a general purpose compression program.
- deleted 9d ago[deleted]
- sedatk 9d agoThe latest release is a year ago, the last commit is two months ago, and the build is failing. The claim “stronger than bzip2” is strange. What does it even mean? Also, comparing parallel decompression benchmarks with bzip2 instead of pbzip2 seems unfair.
- alerque 7d agoIf your basic single purposes tools are getting released every other day that might be a bad sign. The latest release being a year old for a tool like this is not something to worry about. As for your claim that "the build is failing", that is false, and it was false when you wrote this. The CI job for cross compiling to armv6 was failing, but all the other builds were green. You can still check CI status for older releases to confirm my assertion. Now armv6 is fixed too. Maybe dial back the FUD.
- altairprime 9d ago“for fairness, the benchmarks have been performed using single thread mode” (2025) https://news.ycombinator.com/item?id=42902241 https://news.ycombinator.com/item?id=42902241
- finaard 9d agoDepends - if parallel decompression of any bzip3 archive is possible I'd consider it fair, if it requires special flags on archive creation I'd consider it unfair. I didn't see any description about that on that page. pbzip2 only can do parallel decompression on archives created with pbzip2, otherwise it'll fall back to single thread. There nowadays seems to be lbzip2, though, which claims to be able to add SMP support for standard bzip2 archives. I'll need to try that next time I'm working with large archives - I learned about the pbzip2 limitations the hard way last time I was shuffling around a few multi-10GB archives, and was trying to speed things up fully utilising my 32 core threadripper.
- sedatk 9d ago> pbzip2 only can do parallel decompression on archives created with pbzip2 Oh I didn’t know that.
- ot 9d agoThe benchmarks are disingenuous, to the point of looking cherry-picked. The block size for bzip3 is set to 512MB, but the window size for zstd is left to its default (8MB I believe for high levels). So in this corpus, which is made up of all versions of Perl source code concatenated, the window is too small to see all the identical files and just match them. Also corpora made out of very long repetitions are pretty much the best case scenario for BWT-based compressors. If we match the window size of zstd to that of bzip3 we get dramatically different results: % gzcat *.gz | time zstd -T8 -16 | wc -c # baseline 2819113884 zstd -T8 -16 2054.50s user 3.47s system 783% cpu 4:22.80 total % gzcat *.gz | time zstd -T8 -16 --long=29 | wc -c 196405076 zstd -T8 -16 --long=29 1083.06s user 2.41s system 783% cpu 2:18.55 total Almost 15x smaller than the baseline, and more than 2x smaller than bzip3, also CPU time halves (since long matches are found earlier, so there's less work to do). (the baseline number is slightly different because I don't have the exact Perl version set used by the author) Also, in the benchmarks using lrzip, which would make the window size less relevant, zstd is not even compared.
- CJefferson 9d agoWow, that is widely disingenuous, I don't really think there is any excuse for that, I don't believe someone deep in compression algorithms wouldn't know they could adjust the block size, and 512GB is a huge block size for bzip3, as it needs to basically all be in memory so you can't pretend that's just 'the standard value'.
- ot 9d ago> 512GB is a huge block size for bzip3 Sorry! That was a typo, it should have been 512MB (now fixed). Still huge.
- deleted 9d ago[deleted]
- optionalsquid 9d agoHow does memory usage compare between your two runs? The benchmarks report 687M for their run of zstd, and 12178M and 18301M for the two runs of BZip3. Which itself is a bit eyebrow raising
- CodesInChaos 9d agoI think this should include benchmarks zstd with larger windows and long range mode. I wouldn't be surprised if the window they used is smaller than an individual version tar file, which would prevent useful compression.
- altairprime 9d ago“Additional benchmarks on the same dataset” (2025) explores various compression levels with and without long range mode: https://news.ycombinator.com/item?id=42901476 https://news.ycombinator.com/item?id=42901476
- amelius 9d ago> However, the complexity of the algorithms, and, in particular, the presence of various special cases in the code which occur with very low but non-zero probability make it impossible to rule out the possibility of bugs remaining in the program. Sounds like perhaps a nice testcase for formalization + AI?
- teiferer 9d agoIt's beyond me why such foundational libraries don't have formal correctness proofs attached these days.
- winwang 9d agoimo, partially because it's still not easy (in terms of code -> formal proof). With AI, I've been Lean-ifying a simpler (but non-trivial) algo. Pointing (current) AI at it only goes so far and in fact might go "too far" in certain cases, where a non-formalized argument would have sufficed. There's also "who watches the watcher" -- did it really prove what we're supposed to prove? For something like these compression algos, though, I imagine it would be much easier since they already have actual proofs out there.
- mitxela 9d agoformal correctness proof is ridiculously hard, like, insanely hard, have you ever tried writing one for any real algorithm (not a platonic ideal quicksort)?
- teiferer 9d agoI have. And it is ridiculously hard. But having your decompression algorithm not produce what you compressed earlier is also ridiculously bad. So, seems worth the effort, given that AI can do lots the heavy lifting these days.
- deleted 9d ago[deleted]
- JdeBP 9d agoAn interesting unintentional benchmark is to go to https://github.com/iczelia/bzip3/releases https://github.com/iczelia/bzip3/releases and see to what degree bzip3 compresses its own release archives; and go to https://github.com/iczelia/bzip3/blob/master/.github/workflows/release.yml#L23 https://github.com/iczelia/bzip3/blob/master/.github/workflo... to see what options have been chosen for the other compressors here.
- alerque 7d agoAs the one who contributed the autotools build system and CI job for posting source tarballs in various formats, I can assure you it was not "unintentional". Distributing that many different compression formats for the same source archive and even including an uncompressed version of the same archive has little practical purpose except benchmarking / demonstration.
- 8organicbits 9d agoI was processing compressed .jsonl files recently (JSON lines format). I found that lzma gave a much better compression than gzip or bzip2, which helps for archival costs, but it's challenging to work with as software support is lacking. I do duckdb processing which supports gzip transparently. There's an extension for bzip2, but not for lzma or bzip3. I ended up using gzip because it's best supported by the software I use and most likely to have support in software I adopt. But it gave the worst compression results of the options I tried. These bzip3 numbers certainly give me FOMO...
- nvme0n1p1 9d agozstd is the go-to compression format these days. It's even supported in low-level software such as many linux filesystems. I don't know much about duckdb but it looks like it supports zstd too: https://duckdb.org/docs/lts/data/json/loading_json https://duckdb.org/docs/lts/data/json/loading_json
- handsome_jack_ 9d agoOr lz4
- benatkin 9d agoNot really, it's a popular dictionary-based compression format.
- esseph 9d ago”Not really" what? It's hard to understand what point you're trying to make. Can you clarify?
- benatkin 9d agoIt isn't really the go-to compression format, because it isn't ubiquitous like gzip and zip, there are a variety of compression tools out there for different purposes, and there is image/audio/video compression. There is also specialized compression like what git does with its rolling hashes. I think of it as there not being a go-to compression format.
- self_awareness 9d agoAny relation to Iczelion from the masm32 tutorial?
- TonyTrapp 9d agoThose tutorials are about as old as the author of the repository.
- self_awareness 8d agoYes, that's why I was wondering about any relations. But later I've read that there was some kind of Anime called Iczelion (or it was the hero name, whatever). Author also is interested in anime, I guess that's the reason for nickname similarity. Mystery solved.
- sergiotapia 9d ago"DO NOT COMPRESS ANY DATA WITH THIS PROGRAM UNLESS YOU ARE PREPARED TO ACCEPT THE POSSIBILITY, HOWEVER SMALL, THAT THE DATA WILL NOT BE RECOVERABLE." So why would anybody, hobbyist or enterprise, use this? Or does something older like 7zip also have this caveat that I've never experienced.
- fmx 9d agoThis big warning gave me pause, too. Why not have a compression option that automatically checks the data after compression (by decompressing and checking against a hash of the original data), which would reduce the probability of undetected errors to that of a hash collision? i.e. like `7z a` followed by `7z t`, but in one command.
- jubilanti 9d agoIs that all that different than the standard MIT License: > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE....
- ibejoeb 9d agoPractically, no. But that specific disclaimer could lead on to think that there may have been some observed data corruption in practice that isn't disclosed. I have no idea if there is, but I'm not keen to discover it myself. Also practically, this isn't MIT. It is LGPL 3, which I believe includes the warranty terms of GPL 3, i.e., no warranty. So we're in the same place anyway.
- palaiologos 9d agoTool author here. bzip2 also has this clause, in fact it has been lifted from its dist tarball README verbatim. So does lzma, xz, or in practice any open source program that you use.
- IvanK_net 9d agoHey, I am the creator of https://www.photopea.com https://www.photopea.com and if a user decides to publish their work, it compresses PSD files (inside a browser) and sends them to the server for storing. Right now, we have about 2 TB of files. I use the DEFLATE compression which I fully implemented myself (compressor and decompressor, inside a library called UZIP.js). I wish I could use something better :D but it must be implemented in Javascript to run inside a browser, and the library should not be too large (mine is about 8 kB ZIPped). I would love to switch to ZSTD once someone implements a compressor in Javascript that is under 40 - 60 kB. Or do you think that bzip3 could be re-implemented easily in JS using some AI? I really admire you for being so smart at such a young age :) I wish you best of luck in your scientific career! I visited Warsaw this year, but I am not sure if that is where you are from :D
- roschdal 9d agoImagine bzip4
- algorithm314 9d agoBro just decompile agiannis_text
- algorithm314 9d agohttps://codeberg.org/kagiannis/gdcc-2021/src/branch/main/shuffle https://codeberg.org/kagiannis/gdcc-2021/src/branch/main/shu... original source
- spyc 9d agoHow is this source code the original source and which parts? Please elaborate.
- algorithm314 9d agoSource of agiannis_text. He probably decompiled it.
- palaiologos 9d agoTool author here. Sure, out of all bait in this thread I will bite this one. Curiously, it seems like Konstantinos has opened this ticket, i.e. https://github.com/iczelia/bzip3/issues/177 https://github.com/iczelia/bzip3/issues/177, and open-sourced his algorithm here -- https://codeberg.org/kagiannis/gdcc-2021 https://codeberg.org/kagiannis/gdcc-2021. As the allegation is very serious, I will also copy the edited version of this response to my website. I have not seen his tool before, or even was aware of it. However, once you take a closer look, you notice that these two tools could not be more dissimilar. Agiannis' compressor uses a compact context representation to group bytes, followed by RLE and prefix coding. Bzip3 combines repetition removal (here via a run-length code -- prior to the BWT -- and LZP of Charles Bloom), a full Burrows–Wheeler transform, and a richer (thus slower) statistical arithmetic coder. The use of RLE for post-coding the BWT output dates as far back to Julian Seward, perhaps even further. The RLE and LZP are applied before the Burrows-Wheeler transform (as opposed to the implementation in `text', which makes a big difference). Bzip3 uses a proper SAIS library for the forward and backward transforms. Konstantinos' entropy coder seems to use FPC (bytewise prefix codes over adaptively selected subblocks), bzip3 uses an idea similar to this of bcm, which itself descends from Mahoney and ancient work of JS Vitter on arihtmetic coding, where a bitwise arihtmetic coder is input mixed probability estimates from exponential-moving averages with probability refinement. You are welcome to conduct your own analysis, but this is the gist of it -- perhaps Konstantinos has convinced himself that he had invented run-length coding?
- ThiraSoft 9d agoI would be interrested in a comparison with openzl
- Retro_Dev 9d agoThat's like comparing apples to pears. OpenZL is not general purpose. You specify a format for data and it compresses that format. Specifying a general "could be anything" format would be interesting, but I doubt it would compress as well.
- red_admiral 9d agoWhy LGPL when the original license is more permissive? (https://sourceware.org/bzip2/manual/manual.html https://sourceware.org/bzip2/manual/manual.html)
- atiedebee 9d agobzip3 is not made by the same author as bzip2, that's why there is a licence disparity.
- airstrike 9d agoFeels pretty odd to take something named foo2 and claim foo3 on top of it.
- LtWorf 9d agoPlease stop questioning people's choice of license. If you don't like it, you're entitled to not using it.
- bmacho 9d agoDifferent people have different licence preferences. "Why this and not that" questions usually don't spark joy. (Might seem fine for the individual who asks it, but not really in a community.)
- account42 9d agoYou're also entitled to not comment on discussions you're not interested in. License discussion is very much relevant for anything that might end up being used for data interchange.
- LtWorf 8d agoHaving been annoyed by people who asked me to change license several times, I have no sympathy for these requests.
- greyw 9d ago
- charcircuit 9d agoIt's distasteful to use such a name when it's not created by the bzip authors. For some reason open source developers love using would be trademark infringing names instead of coming up with something unique.
- mitxela 9d agoOther than the oppressive trademark law how isn't it bzip3?
- charcircuit 9d agoBecause it's not version 3.0 of bzip, but an entirely different program.
- mitxela 9d agobzip2 isn't compatible with bzip, and the current maintainer of bzip2 made neither bzip nor bzip2.
- charcircuit 9d agoJulian Seward created both bzip and bzip2.
- mitxela 9d agoKamila Szewczyk created bzip3
- deleted 9d ago[deleted]
- mitxela 9d ago[flagged]
- sehw 9d agoFor data recovery of archival stuff it's better to keep it uncompressed, no?
- zamadatix 9d agoDepends on the specific scenario. E.g. efficient compression can speed up recovery from slow media and provide space for increased parity.
- _flux 9d agoSo apparently zamadatix's point wasn't well taken, but I think it could be an effective approach to store the same data twice over to increase the likelihood of successful recovery. Could be even be even ten times, or e.g. 6+4 with redundant recovery coding. Although you do have a point that the compressed data might be more difficult to decipher, if it doesn't have sufficient redundancy to skip bad parts, or if it is essential that the data is aligned in a certain way (e.g. disk images, and probably many other formats) and the format doesn't take this into account. Shorter window sizes, window reset markers, and explicit offset information could mitigate those problems.
- account42 9d agoError correction codes would be a much better use than simply duplicating the data.
- whatever1 9d agoI think compression algorithms are ripe for significant improvement with LLMs. It’s an ideal candidate problem you can have in a closed loop evaluation, and you can just let agent try things.
- Leftium 8d ago> Compression is prediction (According to recent article on HN[1]. So LLMs _are_ compression!) [1]: https://hn.leftium.com/i/49263497 https://hn.leftium.com/i/49263497
- blobbers 9d agoNot sure why this is being posted today or getting comments. bzip3 not a terribly impressive or useful compression algo. benchmark on enwik: https://www.mattmahoney.net/dc/text.html#1703 https://www.mattmahoney.net/dc/text.html#1703
- BorisMelnik 9d agofaster than gzip now or still slower? (sorry I did not read readme)
- deleted 9d ago[deleted]