for-loop 與 json.Unmarshal 性能分析概要

在項目中，常常會遇到循環交換賦值的數據處理場景，尤其是 RPC，數據交互格式要轉為 Protobuf，賦值是無法避免的。一般會有如下幾種做法：

• for
• for range
• json.Marshal/Unmarshal

這時候又面臨 “選擇困難症”，用哪個好？又想代碼量少，又擔心性能有沒有影響啊...

為了弄清楚這個疑惑，接下來將分別編寫三種使用場景。來簡單看看它們的性能情況，看看誰更 “好”

功能代碼

...
type Person struct {
\tName string `json:"name"`
\tAge int `json:"age"`
\tAvatar string `json:"avatar"`
\tType string `json:"type"`
}
type AgainPerson struct {
\tName string `json:"name"`
\tAge int `json:"age"`
\tAvatar string `json:"avatar"`
\tType string `json:"type"`
}
const MAX = 10000
func InitPerson() []Person {
\tvar persons []Person
\tfor i := 0; i < MAX; i++ {
\t\tpersons = append(persons, Person{
\t\t\tName: "EDDYCJY",
\t\t\tAge: i,
\t\t\tAvatar: "https://github.com/EDDYCJY",
\t\t\tType: "Person",
\t\t})
\t}
\treturn persons
}
func ForStruct(p []Person, count int) { 

\tfor i := 0; i < count; i++ {
\t\t_, _ = i, p[i]
\t}
}
func ForRangeStruct(p []Person) {
\tfor i, v := range p {
\t\t_, _ = i, v
\t}
}
func JsonToStruct(data []byte, againPerson []AgainPerson) ([]AgainPerson, error) {
\terr := json.Unmarshal(data, &againPerson)
\treturn againPerson, err
}
func JsonIteratorToStruct(data []byte, againPerson []AgainPerson) ([]AgainPerson, error) {
\tvar jsonIter = jsoniter.ConfigCompatibleWithStandardLibrary
\terr := jsonIter.Unmarshal(data, &againPerson)
\treturn againPerson, err
}

測試代碼

...
func BenchmarkForStruct(b *testing.B) {
\tperson := InitPerson()
\tcount := len(person)
\tb.ResetTimer()
\tfor i := 0; i < b.N; i++ {
\t\tForStruct(person, count)
\t}
}
func BenchmarkForRangeStruct(b *testing.B) {
\tperson := InitPerson()
\tb.ResetTimer()
\tfor i := 0; i < b.N; i++ {
\t\tForRangeStruct(person)
\t}
}
func BenchmarkJsonToStruct(b *testing.B) {
\tvar (
\t\tperson = InitPerson()
\t\tagainPersons []AgainPerson
\t)
\tdata, err := json.Marshal(person)
\tif err != nil {
\t\tb.Fatalf("json.Marshal err: %v", err)
\t}
\tb.ResetTimer()
\tfor i := 0; i < b.N; i++ {
\t\tJsonToStruct(data, againPersons) 

\t}
}
func BenchmarkJsonIteratorToStruct(b *testing.B) {
\tvar (
\t\tperson = InitPerson()
\t\tagainPersons []AgainPerson
\t)
\tdata, err := json.Marshal(person)
\tif err != nil {
\t\tb.Fatalf("json.Marshal err: %v", err)
\t}
\tb.ResetTimer()
\tfor i := 0; i < b.N; i++ {
\t\tJsonIteratorToStruct(data, againPersons)
\t}
}

測試結果

BenchmarkForStruct-4 \t 500000\t 3289 ns/op\t 0 B/op\t 0 allocs/op
BenchmarkForRangeStruct-4 \t 200000\t 9178 ns/op\t 0 B/op\t 0 allocs/op
BenchmarkJsonToStruct-4 \t 100\t 19173117 ns/op\t 2618509 B/op\t 40036 allocs/op
BenchmarkJsonIteratorToStruct-4 \t 300\t 4116491 ns/op\t 3694017 B/op\t 30047 allocs/op

從測試結果來看，性能排名為：for < for range < json-iterator < encoding/json。接下來我們看看是什麼原因導致了這樣子的排名？

性能對比

for-loop

在測試結果中，for range 在性能上相較 for 差。這是為什麼呢？在這裡我們可以參見 for range 的 實現，偽實現如下：

for_temp := range
len_temp := len(for_temp)
for index_temp = 0; index_temp < len_temp; index_temp++ {
 value_temp = for_temp[index_temp]
 index = index_temp
 value = value_temp
 original body
}

通過分析偽實現，可得知 for range 相較 for 多做了如下事項

Expression

RangeClause = [ ExpressionList "=" | IdentifierList ":=" ] "range" Expression .

在循環開始之前會對範圍表達式進行求值，多做了 “解” 表達式的動作，得到了最終的範圍值

Copy

...
value_temp = for_temp[index_temp]
index = index_temp
value = value_temp
...

從偽實現上可以得出，for range 始終使用值拷貝的方式來生成循環變量。通俗來講，就是在每次循環時，都會對循環變量重新分配

小結

通過上述的分析，可得知其比 for 慢的原因是 for range 有額外的性能開銷，主要為值拷貝的動作導致的性能下降。這是它慢的原因

那麼其實在 for range 中，我們可以使用 _ 和 T[i] 也能達到和 for 差不多的性能。但這可能不是 for range 的設計本意了

json.Marshal/Unmarshal

encoding/json

json 互轉是在三種方案中最慢的，這是為什麼呢？

眾所皆知，官方的 encoding/json 標準庫，是通過大量反射來實現的。那麼 “慢”，也是必然的。可參見下述代碼：

...
func newTypeEncoder(t reflect.Type, allowAddr bool) encoderFunc {
 ...
\tswitch t.Kind() {
\tcase reflect.Bool:
\t\treturn boolEncoder
\tcase reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
\t\treturn intEncoder
\tcase reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr:
\t\treturn uintEncoder
\tcase reflect.Float32:
\t\treturn float32Encoder
\tcase reflect.Float64:
\t\treturn float64Encoder 

\tcase reflect.String:
\t\treturn stringEncoder
\tcase reflect.Interface:
\t\treturn interfaceEncoder
\tcase reflect.Struct:
\t\treturn newStructEncoder(t)
\tcase reflect.Map:
\t\treturn newMapEncoder(t)
\tcase reflect.Slice:
\t\treturn newSliceEncoder(t)
\tcase reflect.Array:
\t\treturn newArrayEncoder(t)
\tcase reflect.Ptr:
\t\treturn newPtrEncoder(t)
\tdefault:
\t\treturn unsupportedTypeEncoder
\t}
}

既然官方的標準庫存在一定的 “問題”，那麼有沒有其他解決方法呢？目前在社區裡，大多為兩類方案。如下：

• 預編譯生成代碼（提前確定類型），可以解決運行時的反射帶來的性能開銷。缺點是增加了預生成的步驟
• 優化序列化的邏輯，性能達到最大化

接下來的實驗，我們用第二種方案的庫來測試，看看有沒有改變。另外也推薦大家瞭解如下項目：

• json-iterator/go
• mailru/easyjson
• pquerna/ffjson

json-iterator/go

目前社區較常用的是 json-iterator/go，我們在測試代碼中用到了它

它的用法與標準庫 100% 兼容，並且性能有較大提升。我們一起粗略的看下是怎麼做到的，如下：

reflect2

利用 modern-go/reflect2 減少運行時調度開銷

...
type StructDescriptor struct {
\tType reflect2.Type
\tFields []*Binding
}
...
type Binding struct {
\tlevels []int
\tField reflect2.StructField
\tFromNames []string
\tToNames []string
\tEncoder ValEncoder
\tDecoder ValDecoder
}
type Extension interface {
\tUpdateStructDescriptor(structDescriptor *StructDescriptor)
\tCreateMapKeyDecoder(typ reflect2.Type) ValDecoder
\tCreateMapKeyEncoder(typ reflect2.Type) ValEncoder
\tCreateDecoder(typ reflect2.Type) ValDecoder
\tCreateEncoder(typ reflect2.Type) ValEncoder
\tDecorateDecoder(typ reflect2.Type, decoder ValDecoder) ValDecoder
\tDecorateEncoder(typ reflect2.Type, encoder ValEncoder) ValEncoder
}

struct Encoder/Decoder Cache

類型為 struct 時，只需要反射一次 Name 和 Type，會緩存 struct Encoder 和 Decoder

var typeDecoders = map[string]ValDecoder{}
var fieldDecoders = map[string]ValDecoder{}
var typeEncoders = map[string]ValEncoder{}
var fieldEncoders = map[string]ValEncoder{}
var extensions = []Extension{}
....
fieldNames := calcFieldNames(field.Name(), tagParts[0], tag)
fieldCacheKey := fmt.Sprintf("%s/%s", typ.String(), field.Name())
decoder := fieldDecoders[fieldCacheKey]
if decoder == nil {
\tdecoder = decoderOfType(ctx.append(field.Name()), field.Type())
}
encoder := fieldEncoders[fieldCacheKey]
if encoder == nil {
\tencoder = encoderOfType(ctx.append(field.Name()), field.Type())
}

文本解析優化

小結

相較於官方標準庫，第三方庫 json-iterator/go 在運行時上做的更好。這是它快的原因

有個需要注意的點，在 Go1.10 後 map 類型與標準庫的已經沒有太大的性能差異。但是，例如 struct 類型等仍然有較大的性能提高

總結

在本文中，我們首先進行了性能測試，再分析了不同方案，得知為什麼了快慢的原因。那麼最終在選擇方案時，可以根據不同的應用場景去抉擇：

• 對性能開銷有較高要求：選用 for，開銷最小
• 中規中矩：選用 for range，大對象慎用
• 量小、佔用小、數量可控：選用 json.Marshal/Unmarshal 的方案也可以。其重複代碼少，但開銷最大

在絕大多數場景中，使用哪種並沒有太大的影響。但作為工程師你應當清楚其利弊。以上就是不同的方案分析概要，希望對你有所幫助 :)