摘要：原文地址與性能分析概要前言在項(xiàng)目中，常常會(huì)遇到循環(huán)交換賦值的數(shù)據(jù)處理場(chǎng)景，尤其是，數(shù)據(jù)交互格式要轉(zhuǎn)為，賦值是無(wú)法避免的。如下預(yù)編譯生成代碼提前確定類型，可以解決運(yùn)行時(shí)的反射帶來的性能開銷。

原文地址：for-loop 與 json.Unmarshal 性能分析概要

在項(xiàng)目中，常常會(huì)遇到循環(huán)交換賦值的數(shù)據(jù)處理場(chǎng)景，尤其是 RPC，數(shù)據(jù)交互格式要轉(zhuǎn)為 Protobuf，賦值是無(wú)法避免的。一般會(huì)有如下幾種做法：

for

for range

json.Marshal/Unmarshal

這時(shí)候又面臨 “選擇困難癥”，用哪個(gè)好？又想代碼量少，又擔(dān)心性能有沒有影響啊...

為了弄清楚這個(gè)疑惑，接下來將分別編寫三種使用場(chǎng)景。來簡(jiǎn)單看看它們的性能情況，看看誰(shuí)更 “好”

...
type Person struct {
    Name   string `json:"name"`
    Age    int    `json:"age"`
    Avatar string `json:"avatar"`
    Type   string `json:"type"`
}

type AgainPerson struct {
    Name   string `json:"name"`
    Age    int    `json:"age"`
    Avatar string `json:"avatar"`
    Type   string `json:"type"`
}

const MAX = 10000

func InitPerson() []Person {
    var persons []Person
    for i := 0; i < MAX; i++ {
        persons = append(persons, Person{
            Name:   "EDDYCJY",
            Age:    i,
            Avatar: "https://github.com/EDDYCJY",
            Type:   "Person",
        })
    }

    return persons
}

func ForStruct(p []Person, count int) {
    for i := 0; i < count; i++ {
        _, _ = i, p[i]
    }
}

func ForRangeStruct(p []Person) {
    for i, v := range p {
        _, _ = i, v
    }
}

func JsonToStruct(data []byte, againPerson []AgainPerson) ([]AgainPerson, error) {
    err := json.Unmarshal(data, &againPerson)
    return againPerson, err
}

func JsonIteratorToStruct(data []byte, againPerson []AgainPerson) ([]AgainPerson, error) {
    var jsonIter = jsoniter.ConfigCompatibleWithStandardLibrary
    err := jsonIter.Unmarshal(data, &againPerson)
    return againPerson, err
}

...
func BenchmarkForStruct(b *testing.B) {
    person := InitPerson()
    count := len(person)
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        ForStruct(person, count)
    }
}

func BenchmarkForRangeStruct(b *testing.B) {
    person := InitPerson()

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        ForRangeStruct(person)
    }
}

func BenchmarkJsonToStruct(b *testing.B) {
    var (
        person = InitPerson()
        againPersons []AgainPerson
    )
    data, err := json.Marshal(person)
    if err != nil {
        b.Fatalf("json.Marshal err: %v", err)
    }

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        JsonToStruct(data, againPersons)
    }
}

func BenchmarkJsonIteratorToStruct(b *testing.B) {
    var (
        person = InitPerson()
        againPersons []AgainPerson
    )
    data, err := json.Marshal(person)
    if err != nil {
        b.Fatalf("json.Marshal err: %v", err)
    }

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        JsonIteratorToStruct(data, againPersons)
    }
}

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

從測(cè)試結(jié)果來看，性能排名為：for < for range < json-iterator < encoding/json。接下來我們看看是什么原因?qū)е铝诉@樣子的排名？

在測(cè)試結(jié)果中，for range 在性能上相較 for 差。這是為什么呢？在這里我們可以參見 for range 的 實(shí)現(xiàn)，偽實(shí)現(xiàn)如下：

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
}

通過分析偽實(shí)現(xiàn)，可得知 for range 相較 for 多做了如下事項(xiàng)

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

在循環(huán)開始之前會(huì)對(duì)范圍表達(dá)式進(jìn)行求值，多做了 “解” 表達(dá)式的動(dòng)作，得到了最終的范圍值

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

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

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

那么其實(shí)在 for range 中，我們可以使用 _ 和 T[i] 也能達(dá)到和 for 差不多的性能。但這可能不是 for range 的設(shè)計(jì)本意了

json 互轉(zhuǎn)是在三種方案中最慢的，這是為什么呢？

眾所皆知，官方的 encoding/json 標(biāo)準(zhǔn)庫(kù)，是通過大量反射來實(shí)現(xiàn)的。那么 “慢”，也是必然的?？蓞⒁娤率龃a：

...
func newTypeEncoder(t reflect.Type, allowAddr bool) encoderFunc {
    ...
    switch t.Kind() {
    case reflect.Bool:
        return boolEncoder
    case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
        return intEncoder
    case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr:
        return uintEncoder
    case reflect.Float32:
        return float32Encoder
    case reflect.Float64:
        return float64Encoder
    case reflect.String:
        return stringEncoder
    case reflect.Interface:
        return interfaceEncoder
    case reflect.Struct:
        return newStructEncoder(t)
    case reflect.Map:
        return newMapEncoder(t)
    case reflect.Slice:
        return newSliceEncoder(t)
    case reflect.Array:
        return newArrayEncoder(t)
    case reflect.Ptr:
        return newPtrEncoder(t)
    default:
        return unsupportedTypeEncoder
    }
}

既然官方的標(biāo)準(zhǔn)庫(kù)存在一定的 “問題”，那么有沒有其他解決方法呢？目前在社區(qū)里，大多為兩類方案。如下：

預(yù)編譯生成代碼（提前確定類型），可以解決運(yùn)行時(shí)的反射帶來的性能開銷。缺點(diǎn)是增加了預(yù)生成的步驟

優(yōu)化序列化的邏輯，性能達(dá)到最大化

接下來的實(shí)驗(yàn)，我們用第二種方案的庫(kù)來測(cè)試，看看有沒有改變。另外也推薦大家了解如下項(xiàng)目：

json-iterator/go

mailru/easyjson

pquerna/ffjson

目前社區(qū)較常用的是 json-iterator/go，我們?cè)跍y(cè)試代碼中用到了它

它的用法與標(biāo)準(zhǔn)庫(kù) 100% 兼容，并且性能有較大提升。我們一起粗略的看下是怎么做到的，如下：

reflect2

利用 modern-go/reflect2 減少運(yùn)行時(shí)調(diào)度開銷

...
type StructDescriptor struct {
    Type   reflect2.Type
    Fields []*Binding
}

...
type Binding struct {
    levels    []int
    Field     reflect2.StructField
    FromNames []string
    ToNames   []string
    Encoder   ValEncoder
    Decoder   ValDecoder
}

type Extension interface {
    UpdateStructDescriptor(structDescriptor *StructDescriptor)
    CreateMapKeyDecoder(typ reflect2.Type) ValDecoder
    CreateMapKeyEncoder(typ reflect2.Type) ValEncoder
    CreateDecoder(typ reflect2.Type) ValDecoder
    CreateEncoder(typ reflect2.Type) ValEncoder
    DecorateDecoder(typ reflect2.Type, decoder ValDecoder) ValDecoder
    DecorateEncoder(typ reflect2.Type, encoder ValEncoder) ValEncoder
}

struct Encoder/Decoder Cache

類型為 struct 時(shí)，只需要反射一次 Name 和 Type，會(huì)緩存 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 {
    decoder = decoderOfType(ctx.append(field.Name()), field.Type())
}
encoder := fieldEncoders[fieldCacheKey]
if encoder == nil {
    encoder = encoderOfType(ctx.append(field.Name()), field.Type())
}

文本解析優(yōu)化

相較于官方標(biāo)準(zhǔn)庫(kù)，第三方庫(kù) json-iterator/go 在運(yùn)行時(shí)上做的更好。這是它快的原因

有個(gè)需要注意的點(diǎn)，在 Go1.10 后 map 類型與標(biāo)準(zhǔn)庫(kù)的已經(jīng)沒有太大的性能差異。但是，例如 struct 類型等仍然有較大的性能提高

在本文中，我們首先進(jìn)行了性能測(cè)試，再分析了不同方案，得知為什么了快慢的原因。那么最終在選擇方案時(shí)，可以根據(jù)不同的應(yīng)用場(chǎng)景去抉擇：

對(duì)性能開銷有較高要求：選用 for，開銷最小

中規(guī)中矩：選用 for range，大對(duì)象慎用

量小、占用小、數(shù)量可控：選用 json.Marshal/Unmarshal 的方案也可以。其重復(fù)代碼少，但開銷最大

在絕大多數(shù)場(chǎng)景中，使用哪種并沒有太大的影響。但作為工程師你應(yīng)當(dāng)清楚其利弊。以上就是不同的方案分析概要，希望對(duì)你有所幫助 :)