AeroFTP compressed containers, measured: encryption on and off, format by format

[axpnet]

This is the home thread for one question I keep coming back to: how do AeroFTP's compressed containers actually behave, with and without encryption, across the formats I ship. Rather than assert, I want to measure, format by format, on the same machine, the same corpora, the same harness, and keep the results here so they are comparable over time.

Scope is every container AeroFTP can create or open today. Encrypted first-party: the .aerovault container (v2 and the v3/v4 track, AES-256 with an Argon2id KDF). Plaintext first-party: .aerozip (zstd with integrity checks and Reed-Solomon recovery parity, not confidentiality). General archives: zip and 7z (both with AES-256 on create and extract, and 7z also with header encryption where filenames are hidden), plus tar, tar.gz, tar.xz, tar.bz2, and rar on the extract side. Encrypted overlays and vaults sit alongside: Cryptomator, rclone crypt, and the native AeroCrypt overlay.

One distinction runs through all of this. The primary axis is compression, with or without encryption, where the final size and the ratio are the headline number: that is what the charts below measure, and they are results for the compressed formats. Separate from that are the containers that do not really compress, the encryption-only view of a vault and Cryptomator (which is not even a single file), where compression is not the point and the only things worth comparing are the final weight and the cost of encryption itself. I keep the two lenses apart on purpose, so a store-and-encrypt container is never scored as if it were a compressor.

Two companion threads feed this one. The founding benchmark that started it is the AeroVault comparison in #276, whose data and charts I am migrating here as the baseline. The format-coverage vote, which formats to add next, lives in #365 under the Roadmap label. This thread is the measurement hub the other two point at.

Methodology, so the numbers are trustworthy. Every format is driven through the one AeroFTP CLI, so the comparison is self-consistent: same binary, same clock, same I/O path, timed under /usr/bin/time -v, three repetitions with the median reported. Every single row is round-trip verified, compress then extract, with the SHA-256 of the recovered file matching the original. Corpora are deterministic and seeded, spanning the honest range from compressible prose and logs to incompressible random bytes, so the picture is not cherry-picked.

---

Founding benchmark (migrated from #276): AeroVault v3 vs zip / 7z / tar

Superseded by the July 2026 benchmark refresh below (aeroftp 4.1.2, full roster, encryption on and off). These founding numbers are kept for history.

The corpora span the honest range from compressible to incompressible:

Corpus	Shannon entropy (bits/byte)	Nature
text	4.38	English-ish prose
random	8.00	CSPRNG bytes (incompressible)
logs	4.82	repetitive structured logs
mixed	6.10	50% prose / 30% logs / 20% random

Compressed size as a percentage of original, by corpus

text corpus at 32 MiB

Format	% of orig	% saved	Comp MB/s	Ext MB/s	Peak RSS MB	Enc
aerovault-fast	21.7	78.3	31.5	49.9	180	AES
aerovault-balanced	20.5	79.5	20.0	49.8	180	AES
aerovault-archive	15.6	84.4	2.0	52.7	180	AES
zip-aes	19.2	80.8	27.4	275.9	84	AES
7z-aes	15.1	84.9	0.9	63.1	131	AES
tar.gz	19.3	80.7	28.5	336.9	55	-
tar.xz	15.1	84.9	1.2	102.2	131	-
tar.bz2	12.8	87.2	11.3	39.4	55	-

The speed vs size tradeoff, with the Pareto frontier

Compress and extract throughput

Peak memory during compress, and time vs input size

---

What is coming next in this thread

I am refreshing and widening this benchmark to the full roster, encryption on and off, including the plaintext .aerozip lane and the header-encrypted 7z mode, and adding a level sweep for 7z. That last one matters: the June run noted that 7z ignored the compression level and ran a fixed preset, and that is now fixed, so I want to show the ratio and speed curve the level knob finally produces. New charts for the level sweep and for the pure encryption overhead will land here when the run completes.

If you have a format you want measured, or a corpus that reflects your real files better than my seeded ones, say so below and I will fold it into the next run.

[axpnet]

July 2026 benchmark refresh (aeroftp 4.1.2)

I re-ran the full compressed-container benchmark on the current release. This refresh supersedes the June table above as the reference dataset: same deterministic corpora (seed b3c0de01, byte-identical to June, verified by SHA-256), but explicit --level 5 on every leveled format and a binary where the 7z level flag is actually honored.

Why the numbers moved since June (no regression). Three measurement differences, all verified against git history and byte-identical corpora:

1. The AeroVault archive profile changed from zstd -19 to zstd -15 in v4.0.8 (commit 834ee5f6, a deliberate speed-for-ratio trade). June ran 4.0.4, so its aerovault-archive text ratio was 15.6% where 4.1.2 measures 17.4%.
2. The June harness passed no --level, so every format ran at the 4.0.4 CLI defaults (gzip/xz 6, bzip2 9, 7z default preset). The July harness pins --level 5 everywhere, which is why zip/gz/xz rows shifted by 1-2 pp.
3. 4.0.4 ignored --level on 7z entirely (noted in the June findings). The wiring shipped since, and the level sweep below proves it works.

Method. 4 deterministic corpora (text, logs, mixed, random) at 256 KiB / 4 MiB / 32 MiB, median of 3 reps under /usr/bin/time -v, every row SHA-256 round-trip verified, 210 rows total, zero round-trip failures.

Test environment. Intel Core i7-9750H (6c/12t, AES-NI), 62 GiB RAM, Linux 6.8, aeroftp 4.1.2 release build. Compression ratios are machine-independent (same input, format and level produce the same bytes anywhere). Absolute speeds are machine-specific; relative rankings hold on same-class x86_64 hardware with AES-NI, and would shift mainly on CPUs without AES-NI (higher encryption overhead), very different core counts, or slow storage (the tar store baseline is I/O-bound, the compressors are CPU-bound).

Compressed size

tar.bz2 is the density leader on text (12.8%), with 7z/xz at 15.4% and the zip/gz family at 20.8%. aerovault-archive lands at 17.4% (zstd -15) and aerovault-fast at 21.7% (zstd -3), both inside the encrypted-container envelope you would expect from their profiles.

Ratio vs speed (Pareto)

The rational picks on text at 32 MiB: tar.bz2 (smallest), aerovault-balanced, zip-plain and tar.gz (fastest real compressors). tar (store, 100% at 498 MiB/s) is annotated off scale so the real compressors keep a readable axis.

Throughput and wall-clock

Memory and scaling

Peak RSS stays flat per family (zip/gz ~60 MiB, 7z/xz ~136 MiB, AeroVault ~188 MiB including the Argon2id KDF arena). Compress time scales linearly with input size; the AeroVault intercept is the intentional KDF floor, not codec cost.

7z level sweep (now honored)

Level 1 to 5 buys most of the ratio (23.2% to 15.4% on text); 5 to 9 buys another half point for 16-19% more time. The plain and AES series overlap on ratio at every level: encryption does not change the compressed payload.

Encryption overhead

zip and 7z AES twins cost 0.0 pp in size at every corpus (rounded to one decimal; the AES container adds a constant few KiB of headers and salts), and 2.7% to 6.8% compress speed on text (AES-NI hardware; expect more on CPUs without it). The first-party row compares the encrypted vault default (aerovault-fast, zstd -3) against the plaintext aerozip archive profile (zstd -15), so it mixes profile and encryption effects by design: +4.3 pp size for +432% speed on text is the profile trade, not an encryption tax.

Full CSV (210 rows) and the harness are available; ask and I attach them.

[axpnet]

Native cross-check: is AeroFTP's output the same as the reference tools?

The benchmark above compares formats against each other, but it cannot answer a sharper question: does AeroFTP's implementation of each format produce the same bytes as the canonical tool? So I fed the exact same corpus bytes to AeroFTP and to the native tools (gzip, xz, bzip2, zip, 7-Zip 23.01) at the same levels: 42 comparisons, every row round-trip verified on both sides, zero failures.

Result: at standard and maximum levels, AeroFTP is the format, not an approximation of it.

• xz and bz2: byte-identical to native output at every level tested, including level 1.
• gz and zip: byte-comparable at level 6 (-0.7%) and level 9 (+0.05%).
• 7z: within 0.14% of 7-Zip at levels 5 and 9.
• zip on incompressible data: identical at every level (both sides store).

The honest caveat: level 1 is a different point on the curve. At --level 1, AeroFTP's DEFLATE (gz/zip through flate2 with the zlib-rs backend selected in this build) produces +40% larger output than gzip -1 on text (+21% mixed, +5% random). I measured why: zlib-rs maps level 1 to its deflate_quick algorithm, a speed-first point below the traditional gzip/Info-ZIP fast preset, not a broken encoder. On the same 32 MiB text corpus, AeroFTP gz L1 finishes in 0.16 s where gzip -1 takes 0.40 s, so it trades ratio for roughly 2.4x speed. AeroFTP L2 is already back in the native fast band: 8.50 MiB in 0.26 s on this corpus, compared with gzip -1 at 8.82 MiB in 0.40 s and gzip -2 at 8.51 MiB in 0.46 s. 7z at level 1 is +6.9% on text (+2.3% mixed) because our level 1 maps to the same LZMA2 preset as xz -1 (the outputs are byte-identical to xz), while 7-Zip's -mx1 picks a slightly different preset.

So the practical guidance: if you use level 1 for maximum speed, AeroFTP gives you a deliberately faster DEFLATE point than the native tools at that setting; if you want the native fast-ratio neighborhood, use level 2+, and use level 6+ or a denser format when size matters more than speed. The level-1 mapping is recorded as a known, documented trade-off rather than a round-trip or format bug.

Method and environment as in the post above: deterministic corpora, seed b3c0de01, 32 MiB per corpus, aeroftp 4.1.2 vs distro gzip/xz/bzip2/zip and 7-Zip 23.01, Intel i7-9750H, Linux 6.8. Size deltas are machine-independent; the L1 timing ratio is machine-specific but the ordering is structural (fewer match probes per byte).

[axpnet]

Follow-up on the level-1 caveat above: I decided not to leave it as a documented trade-off and fixed the mapping instead, so the red +40% bars in the charts above no longer describe the app.

The +40% came from the DEFLATE backend in this build (zlib-rs through flate2, pulled in by the zip crate), which maps level 1 to its deflate_quick algorithm, a speed-first preset below the traditional gzip -1 point. Backend level 2 already beats gzip -1 on both axes on this corpus (8.50 MB in 0.26 s vs 8.82 MB in 0.40 s), so user-facing DEFLATE level 1 is now pinned to backend level 2 for gz, zip, tar.gz and the size estimator, on every surface (GUI, CLI, MCP, AI tools share the same core). Levels 0 and 2-9 are untouched, and levels 1 and 2 now emit identical streams by design, guarded by two new unit tests.

Same cross-check, same corpora and seed, re-run on the patched build:

Row	Pre-fix (charts above)	Post-fix
text gz L1 vs gzip -1	+40.33%	-3.64% (smaller, and still faster: 0.27 s vs 0.40 s)
text zip L1 vs Info-ZIP -1	+40.33%	-3.64%
mixed gz / zip L1	+20.57%	-1.52%
every other row (42 total)	-	byte-unchanged, 42/42 round-trips pass

One legend refinement in these re-run charts: beyond the 3% band the color now encodes direction, red stays "investigate" (AeroFTP larger than native) while purple marks "smaller than native", because AeroFTP beating the native preset on size is not a defect to investigate. That purple pair on text L1 is the fixed mapping: smaller than gzip -1 at the same level. The only red bar left is 7z L1 (+6.9% on text), which is the known preset-mapping difference already covered above: our level 1 output is byte-identical to xz -1, while 7-Zip's -mx1 picks a slightly different LZMA2 preset.

So the charts in the post above show the pre-fix build and stay as the honest record of what the cross-check caught; these are the same 42 comparisons after the fix. The change landed on main and ships in v4.1.3.

Closing thought: tests like this are interesting to run in themselves, because they tend to surface gaps you did not know you had, and closing those gaps carries the pleasant risk of ending up with a better product.

Note

The one red bar left (7z level 1: +6.9% on text, +2.3% on mixed) is a different preset-table story, untouched by this fix: AeroFTP's 7z level 1 emits the same LZMA2 point as xz -1 (the compressed stream is byte-identical to xz), while 7-Zip's -mx1 picks its own, slightly denser fast preset. A follow-up investigation is already queued to evaluate mirroring 7-Zip's mx1 parameters at our level 1, bench first, same protocol as this fix.

[axpnet]

7z level-1: evaluated, documented (no pin)

Following up on the 7z level-1 residual I flagged in the cross-check above, I ran the bench-first evaluation (seed b3c0de01, 32 MiB text and mixed, best-of-3, cross-extraction on every row):

• The +6.9% (text) / +2.3% (mixed) vs 7z -mx1 is invariant to dictionary size: AeroFTP L1 at 256 KiB, 1 MiB and 8 MiB all land within 252 bytes of each other, so --dictionary (the only exposed lever) cannot close it. AeroFTP already uses a larger dictionary than 7z -mx1 (1 MiB vs 256 KiB) and is still larger, which rules the dictionary out.
• The gap is inherent to the fast-mode (HC4) parse of the LZMA2 backend, not a level-mapping bug. AeroFTP 7z L1 is byte-identical to xz -1, a standard "Fastest" baseline.
• Closing it would mean emitting preset 2 at user level 1: about +35% time at the level whose whole point is speed, and it would break the L1 == xz -1 parity and collapse levels 1 and 2 into an identical stream.

Decision: documented, no pin. This is the inverse of the DEFLATE level-1 fix, which was pathological (+40% larger than gzip -1) and worth pinning to backend level 2; 7z level 1 is a defensible speed-first point that happens to match xz -1 exactly. Levels 2 to 9 and the xz path stay byte-identical.

On interoperability, which matters more than any single-level ratio: cross-extraction is 12/12 both ways in the 32 MiB run, and a dedicated small-file interop matrix passes 18/18 across every format AeroFTP can create (zip, 7z, tar, tar.gz, tar.xz, tar.bz2, gz, xz, bz2), in both directions. What AeroFTP writes opens in the native tools, and what the native tools write opens in AeroFTP.