量出來的，不是宣稱的

ANLA 對真實位元組做了什麼

五個情境，跑在這個儲存庫自己的 git 歷史上，並且跟一般人真的會拿來用的替代方案對比。每一個數字都由 bench/run_bench.py 產生並寫進一份 JSON，這個頁面是從那份 JSON 生成的——所以頁面說不出任何量測程式沒有量到的東西，包含 ANLA 輸掉的那幾列。

▸ 去重跟壓縮是兩種不同的機制。 Zstandard 於 2026-08-07 落地；在那之前，這裡每一個數字都只是去重，而單一 snapshot 比它所包的樹還大。在它曾經輸掉的那幾列，「store 單獨」那一行仍然留在壓縮結果旁邊——一個惄惄把自己輸過的情境拿掉的基準，不是在回報，是在行銷。

量測於 2026-08-15 05:25 UTC · 71a719f組態: ANLA 1.0 (draft) · codec store, zstd · anla-cdc-1 · blake3-256Python 3.14.5

這個儲存庫的 python/ 目錄，單一 snapshot

ANLA 1.0 只儲存，不壓縮。所以單一 snapshot 會比原樹更大，兩種壓縮器都贏它。這一列就是「該做 Zstandard」這個主張，寫成一次量測。

ANLA 1.0 (zstd + anla-cdc-1)793.9 KiB

ANLA-MVP (deflate)868.2 KiB

ZIP, deflate -9835.4 KiB

tar.gz -9731.3 KiB

ANLA 1.0, codec turned off2.10 MiB

34% 為輸入的 2.29 MiB

500 個檔案：命名空間化的 metadata 跟 500 個 symlink 多花了多少

Milestone 2 不會移動任何一個壓縮數字，因為它本來就不是在談壓縮——它是「讓工具能打包以前直接拒絕的樹」。這就是它在 manifest 裡、每個物件的帳單。

ANLA 1.0 (zstd + anla-cdc-1)329.7 KiB

no_metadata253.5 KiB

times_only271.1 KiB

times_and_mode278.5 KiB

4280% 為輸入的 7.7 KiB

python/ 連續 8 個 commit，每個一個 snapshot

每一個版本都逐位元可還原。對照組是「每個版本各存一個 ZIP」——沒有 snapshot 的人就是這樣做的——以及「全部版本一個 tar.gz」。gzip 的視窗只有 32 KB，看不到從這一份原始碼樹到下一份，這正是為什麼去重是另一套機制，而不是比較差的壓縮。

ANLA 1.0 (zstd + anla-cdc-1)390.5 KiB

ZIP per version, deflate -91.50 MiB

tar.gz, all versions at once1.25 MiB

ANLA 1.0, codec turned off825.2 KiB

9% 為輸入的 4.42 MiB

每個 snapshot 的位元組去了哪裡

新內容，對比「描述它」的代價。manifest 描述的是它整個 snapshot 而不是差異，這一欄就是那個決定的價格。

第幾個	新內容	描述資料
1	173.7 KiB	17.8 KiB
2	7.7 KiB	18.6 KiB
3	4.5 KiB	18.9 KiB
4	8.6 KiB	19.3 KiB
5	6.2 KiB	19.3 KiB
6	24.2 KiB	21.4 KiB
7	3.6 KiB	21.4 KiB
8	3.9 KiB	21.4 KiB

同一個目錄連續 snapshot 五次，內容完全沒變

去重的上限。第 2 到第 5 個 snapshot 只多了一份 manifest 跟一個 footer，所以它們的成本就是 snapshot 設計裡第一個決定的價格：manifest 描述的是它整個 snapshot，而不是差異。

ANLA 1.0 (zstd + anla-cdc-1)127.8 KiB

ZIP per copy, deflate -9233.6 KiB

23% 為輸入的 557.4 KiB

每個 snapshot 的位元組去了哪裡

新內容，對比「描述它」的代價。manifest 描述的是它整個 snapshot 而不是差異，這一欄就是那個決定的價格。

第幾個	新內容	描述資料
1	112.2 KiB	3.0 KiB
2	0.0 KiB	3.1 KiB
3	0.0 KiB	3.1 KiB
4	0.0 KiB	3.1 KiB
5	0.0 KiB	3.1 KiB

2 MB 隨機位元組，然後同一個檔案再來一次

這種資料沒有東西壓得動，也不該壓得動。第一個 snapshot 比原檔略大；第二個幾乎不用錢——去重不在乎位元組壓不壓得動。

ANLA 1.0 (zstd + anla-cdc-1)1.91 MiB

ZIP per copy, deflate -93.82 MiB

tar.gz, both copies3.82 MiB

50% 為輸入的 3.81 MiB

每個 snapshot 的位元組去了哪裡

新內容，對比「描述它」的代價。manifest 描述的是它整個 snapshot 而不是差異，這一欄就是那個決定的價格。

第幾個	新內容	描述資料
1	1.91 MiB	3.1 KiB
2	0.0 KiB	3.1 KiB

3 MB 檔案，然後在最前面插入 64 個位元組

固定切塊撐不過的情境：每一個邊界都位移了，所以沒有任何一個 chunk 對得上，整個檔案被存第二次。內容定義的邊界跟著內容走，所以只有真正改變的 chunk 是新的。

ANLA 1.0 (zstd + anla-cdc-1)3.14 MiB

ANLA 1.0, fixed chunking5.73 MiB

55% 為輸入的 5.72 MiB

每個 snapshot 的位元組去了哪裡

新內容，對比「描述它」的代價。manifest 描述的是它整個 snapshot 而不是差異，這一欄就是那個決定的價格。

第幾個	新內容	描述資料
1	2.86 MiB	3.7 KiB
2	277.0 KiB	3.8 KiB

64 MiB 不可壓縮資料，打包與驗證

每秒多少 MiB，在跑這次量測的機器上。內容定義切塊是預設值——因為固定切塊會讓去重整個垮掉——而在 Python writer 裡它同時也是慢路徑，慢兩個數量級。Rust writer 做的是完全一樣的工作，產生逐位元相同的封裝，速度是 28 倍；所以這是實作的數字，不是格式的數字。會publish 出來，是因為一個只量自己擅長的項目的專案，等於沒有在量。

Python writer, fixed chunking64.4 MiB/s · 4.52 h/TiB

Python writer, anla-cdc-1 (the default)3.8 MiB/s · 76.65 h/TiB

Python reader, verify538.1 MiB/s

Rust writer, anla-cdc-1107.3 MiB/s · 2.71 h/TiB

這張表指出接下來該做什麼

一棵原始碼樹的單一 snapshot，是同一棵樹 tar.gz 的 1.1 倍（Zstandard 落地前是 2.9 倍）。它仍然輸，而且是結構性的理由而不是少了功能：tar.gz 跨檔案邊界壓縮，而 ANLA 每一塊各自壓，為的是任何一塊都能不靠其他塊讀出來。
同一棵樹的八個版本，是「八個版本包成一個 tar.gz」的 0.30 倍；把 codec 關掉則是 0.64 倍。贏的主力是去重，壓縮在上面相乘。跟 tar.gz 不同的是，任何一個版本都能單獨取出，而且第九個可以附加上去而不重寫任何一個位元組。
描述一個 snapshot 的成本，第一個是 17.8 KiB、第八個是 21.4 KiB，並且佔了後續 snapshot 所新增內容的 71%。manifest 描述的是它整個 snapshot 而不是差異；FLAG_COMPRESSED_METADATA 就是用來阻止那個比例無限地成長下去。
在一個 3 MB 檔案最前面插入 64 個位元組，內容定義邊界的成本是 280.8 KiB，固定切塊是 2.86 MiB——多了 10.4 倍。這就是 anla-cdc-1 存在的理由。

自己重跑一次: python bench/run_bench.py — 原始碼採私人存取