snappy:google 開源的快速、無損壓縮包

大家好,我是漁夫子。

今天給大家推薦的是一個 google 開源的快速、無損的壓縮包:snappy。

snappy 算法是 google 開源的。該包是 google 使用 go 語言來實現的。項目地址如下:

項目地址:https://github.com/golang/snappy

星標:1.4k

使用者:97.7k

簡介

該包的目標並不是最大化的壓縮比例,也不是和其他壓縮庫兼容;相反,snappy 算法的目標是在合理的壓縮率下儘可能的提高壓縮速度

例如,與 zlib 的最快壓縮模式相比,snappy 依然比其快了一個數量級,但產生的壓縮文件要比 zip 的大 20% 到 100%。

特性

snappy 壓縮算法具有以下特性:

性能

Snappy 的目標是快速。在 64 位模式下,一個 Corei7 處理器的單核上,其壓縮速度約爲 250MB / 秒或更快,解壓縮速度約爲 500MB / 秒或更快。(這些數字是在我們的基準測試套件中最慢的輸入情況下得出的;其他輸入會快得多。)在我們的測試中,Snappy 通常比同一級別的算法(如 LZO、LZF、QuickLZ 等)更快,同時實現了類似的壓縮率。

示例

我們看下 snappy 的使用。如下:

package main

import (
    "fmt"
    "github.com/golang/snappy"
)

func main() {
    fmt.Println([]byte("aaa"))
    src1 := []byte("akakakakakakakakakakdddddddddcccccceeeeeeeegggggggggsssss")

    var dst1 []byte
    c := snappy.Encode(dst1, src1)
    fmt.Printf("src1 before compression len:%d\n", len(src1)) 
    fmt.Printf("src1 after compression len:%d\n", len(c))
}

運行代碼,可知壓縮前字符串是 57 個字節,壓縮後是 34 個字節。結果如下:

src1 before compression len:57
src1 after compression len:34

但是,有時候你會發現,壓縮後會比壓縮前字節數變大。這是和原字符串有關係,如果原字符串中重複的字符越少,那麼壓縮後的長度就有可能會比之前變長。如果原字符串中重複的字符比較多,那麼壓縮比率就會很高。這也是壓縮的基本原理。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/ie7LqXZQOUX0Bfn4QhHzLA