有時候，快就是全部

資料庫正在寫日誌、訊息佇列正在搬訊框、遊戲引擎正在從磁碟載入資源——在這些路徑上，資料根本沒時間等壓縮演算法慢慢想。這套函式庫就是為那一刻而生的。它是一套開源的無損壓縮函式庫，單核壓縮速度超過 500 MB/s，解壓則達到每核數 GB/s；實務上這意味著它撞到的是記憶體頻寬這道牆，而不是演算法本身。

取捨講得很白：壓縮率被讓出去，換回來的是低到可以塞進即時路徑裡的延遲。整個設計就是這樣，也解釋了為什麼它出現在那些沒有人在計算省下多少磁碟的地方。

快，但留了一手

總有些日子，壓縮率比時鐘更重要。一個高壓縮變體願意多花處理器時間換更好的結果；字典壓縮則在 API 與命令列兩層都有，在小檔案上——單一緩衝區裡的歷史太短——正是字典讓數字變得體面。

1.10.0 這一版副標題就叫多核版，把執行緒變成正式功能：Windows 上預設開啟，執行緒數量用環境變數控制，字典 API 也從實驗狀態畢業成穩定介面。格式規範公開，訊框格式與區塊格式都有完整說明，各語言的綁定也一應俱全。

看不見的功臣

它採用兩條款的 BSD 授權，於是把它放進商業產品裡，不必做任何授權功課。這份自由正是它早就不再是「一個壓縮工具」的原因：資料庫、檔案系統、核心模組、封存格式都直接把它嵌在裡面，而套件庫裡那個函式庫名字，也是發行版裡的常客。對開發者來說，它更接近基礎設施而不是軟體——呼叫一個函式，使用者永遠不會知道它的名字，唯一感覺到的是「快」。

它「不是什麼」也該說得同樣清楚。它不會產生最小的檔案；當目標是省頻寬或省磁碟，更重的演算法會贏，也該派它上場。它不是備份格式，不是壓縮軟體，也不是人會直接互動的東西。它的工作，是在別人的程式裡消失。

怎麼誠實地讀一組數字

這種數字很容易被誤用，所以值得說清楚它們代表什麼。單核測出來的吞吐量描述的是演算法，不是你的應用程式：真實的管線還有複製、鎖、網路往返與序列化，而資料一旦跨過一個 socket，壓縮器的優勢就縮小了。誠實的評估方式是量自己真正在跑的那條路徑，誠實的選擇方式則是先問：瓶頸是時間，還是空間。

它在真實專案裡是怎麼被選中的

這種決定很少是函式庫之間的比賽。它通常以一句話的形式出現在設計討論裡：這份日誌不需要小，它需要在下一筆交易提交之前寫完。一旦要求變成這樣，討論就結束了，因為那些能產出更小檔案的候選，正好就是來不及的那些。

整合的規模也因此很節制：一個緩衝進去，一個緩衝出來，中間是別的工具已經看得懂的訊框格式——這是公開規範的隱性優勢，今天寫下的檔案，可以讓另一個語言寫的另一個程式讀出來。出錯的時候，錯誤通常是大小或版本對不上，而不是一個謎；在凌晨三點，這件事值很多。

天花板究竟在哪裡

值得再說一次：天花板是機器，不是演算法。儲存與記憶體已經快到讓一個以這種速度工作的壓縮器，大半時間在等位元組送達，所以再往上推，換到的比看起來少：剩下的空間在周圍那個程式裡，不在這套函式庫裡。

這也解釋了這個專案這些年來的形狀變化。有意思的工作，從「讓核心更快」移到「讓它更容易被正確使用」：多執行緒、穩定的字典介面、寫得夠好以致於可以有第二個實作的格式說明。對基礎設施來說，「無聊」與「可靠」是同一句讚美。

壓縮這件事的取捨一直是速度與壓縮率，而這套函式庫把天平徹底壓向速度那一端，再用寬鬆的授權與十多年的穩定維護守住那個位置。需要省頻寬、省磁碟時它未必是最佳解；需要省時間時，它幾乎總是第一個候選。