Cram started much smaller. I wanted to unzip a large file faster, looked at why it was slow, and found that 7-Zip and Info-ZIP both extract a .zip on a single core, even though every entry in the format is independently addressable and always has been. So I wrote a parallel unzip. Pulling on that turned up the same gap almost everywhere else. Writing a .tar.xz ran on one core. So did a .7z holding one large file. Most of Cram is that observation applied repeatedly, plus a governor that measures the machine instead of assuming one, because the balance between decode speed and disk write speed is completely different on my two test boxes and a fixed answer is wrong on both. The native format came later and is the part I'd defend hardest. Content- defined chunking means repeated data is stored once even when it sits at different offsets inside different files, which no setting on 7-Zip or WinRAR will do. Being upfront about the shape of it: Windows, Linux and Apple Silicon macOS all build and run the full suite, but mounting an archive as a folder is Windows- only and so is the GUI. What I'd ask for is scrutiny of the numbers. BENCHMARKS.md has a section on where Cram loses, which is mostly ratio against 7-Zip on data with no duplication, and memory against nearly everyone. The corpus is a 2.22 GiB download with a published SHA256 and a script that rebuilds it byte-for-byte from public sources, so you can check the table rather than take it. Happy to answer anything.

Cram

Multi-format archive tool, 6-11x faster than 7-Zip

Multi-format archive tool, 6-11x faster than 7-Zip