今天我們開源Jingo，這是一個用於golang的快速JSON庫。https://github.com/bet365/jingo
go標準庫json編碼器實現的接口非常好 - 你使用標籤裝飾你的結構然後將它們傳遞給Marshal，就像這樣......
encoding/json 的用法示例：
import "encoding/json"
type MyPayload struct {
Name string `json:"name"`
Age int `json:"age"`
ID int `json:"-"`
}
func main(){
p := MyPayload{
Name: "Mr Payload",
Age: 33,
}
serialized, err := json.Marshal(&payload)
// serialized = {"name":"Mr Payload","age":33}
}
在大多數情況下，這可能是您所需要的，但在高性能方案中，此默認實現可能會成為瓶頸。這導致了由Go社區驅動的相當多的其他JSON實現的創建，每個實現都以不同程度的成功和實現成本解決了性能問題。一般來說，庫越快，您的結構越適合支持庫就越困難。
理想情況下，我們想要的是與標準庫相同（或類似）的界面，但是像gojay這樣的其他庫能夠實現的所有性能優勢。
所以Jingo就是我們最終得到的，而這就是它的相似之處
Jingo的示例用法
import "github.com/bet365/jingo"
type MyPayload struct {
Name string `json:"name"`
Age int `json:"age"`
ID int
}
var enc = jingo.NewStructEncoder(MyPayload{})
func main() {
p := MyPayload{
Name: "Mr Payload",
Age: 33,
}
buf := jingo.NewBufferFromPool()
enc.Marshal(&p, buf) // buf = {"name":"Mr Payload","age":33}
}
與前一個示例的主要區別在於我們使用我們想要編碼的類型的空白結構創建了一個新的編碼器實例，它就是我們稱之為Marshal的實例。
下一個區別是我們正在使用我們自己的輕量級緩衝區類型來強制使用緩衝區，該緩衝區類型內置了池。
當我們使用緩衝區的內容時，我們調用buf.ReturnToPool()它以便可以重複使用，這大大減少了我們的內存分配總體。
它是如何工作的？
當您創建編碼器的實例時，它會遞歸地生成一個指令集，該指令集定義瞭如何迭代編碼結構。
這使它能夠提供清晰的API，但具有與構建時優化編碼器相同的優點。
它幾乎完全能夠在這個編譯階段完成所有類型的斷言和反射活動，然後unsafe在指令集執行（Marshal調用）期間充分利用包來使讀取和寫入非常快。
作為指令集編譯的一部分，它還生成靜態元數據，即字段名稱，括號，大括號等。然後根據需要將這些元數據分塊。
使用上面示例中的數據，並稍微簡化調用堆棧，我們最終得到的是一組輕量級指令，看起來像這樣
write_buf `{"name":"`
write_buf_from_ptr `Mr Payload`
write_buf `","age":`
write_buf_from_ptr `33`
write_buf `}`
正如我們已經提到的，所有類型信息都被推斷為生成指令集的一部分，因此每條指令都知道要讀取的確切結構偏移量和大小。
您現在可以使用的編碼器是jingo.StructEncoder和jingo.SliceEncoder。這些覆蓋了我們自己的絕大多數用例，但很快就會出現地圖編碼器。
它的表現如何？
非常好，因為它發生了。看一看下面的附圖中，它們與生成的gojay Perf數據，SmallPayload和LargePayload分別。
這些結果可能更加明顯，具體取決於結構的形狀 - 這些結果基於具有大量字符串數據的結構：
Jingo實際上比我們現在能找到的任何東西都快，所以我們開源並與更廣泛的社區分享似乎是一個很好的候選人。
社區貢獻
說到，Jingo歡迎捐款。請參閱https://github.com/bet365/jingo以獲取一系列指導原則。
未來
我們有興趣看看我們能夠在多大程度上採用構成編碼器基礎的一系列構思。因此，雖然解碼器在卡上，但可能有其他應用程序和編碼格式可以從這種方法中受益。
與此同時，如果您選擇這樣做，我們很想聽聽您使用Jingo的經歷！
閱讀更多 guorenweitianxia 的文章
