1.7 for-loop 与 json.Unmarshal 性能分析概要
在项目中,常常会遇到循环交换赋值的数据处理场景,尤其是 RPC,数据交互格式要转为 Protobuf,赋值是无法避免的。一般会有如下几种做法:
    for
    for range
    json.Marshal/Unmarshal
这时候又面临 “选择困难症”,用哪个好?又想代码量少,又担心性能有没有影响啊...
为了弄清楚这个疑惑,接下来将分别编写三种使用场景。来简单看看它们的性能情况,看看谁更 “好”

功能代码

1
...
2
type Person struct {
3
Name string `json:"name"`
4
Age int `json:"age"`
5
Avatar string `json:"avatar"`
6
Type string `json:"type"`
7
}
8
9
type AgainPerson struct {
10
Name string `json:"name"`
11
Age int `json:"age"`
12
Avatar string `json:"avatar"`
13
Type string `json:"type"`
14
}
15
16
const MAX = 10000
17
18
func InitPerson() []Person {
19
var persons []Person
20
for i := 0; i < MAX; i++ {
21
persons = append(persons, Person{
22
Name: "EDDYCJY",
23
Age: i,
24
Avatar: "https://github.com/EDDYCJY",
25
Type: "Person",
26
})
27
}
28
29
return persons
30
}
31
32
func ForStruct(p []Person, count int) {
33
for i := 0; i < count; i++ {
34
_, _ = i, p[i]
35
}
36
}
37
38
func ForRangeStruct(p []Person) {
39
for i, v := range p {
40
_, _ = i, v
41
}
42
}
43
44
func JsonToStruct(data []byte, againPerson []AgainPerson) ([]AgainPerson, error) {
45
err := json.Unmarshal(data, &againPerson)
46
return againPerson, err
47
}
48
49
func JsonIteratorToStruct(data []byte, againPerson []AgainPerson) ([]AgainPerson, error) {
50
var jsonIter = jsoniter.ConfigCompatibleWithStandardLibrary
51
err := jsonIter.Unmarshal(data, &againPerson)
52
return againPerson, err
53
}
Copied!

测试代码

1
...
2
func BenchmarkForStruct(b *testing.B) {
3
person := InitPerson()
4
count := len(person)
5
b.ResetTimer()
6
for i := 0; i < b.N; i++ {
7
ForStruct(person, count)
8
}
9
}
10
11
func BenchmarkForRangeStruct(b *testing.B) {
12
person := InitPerson()
13
14
b.ResetTimer()
15
for i := 0; i < b.N; i++ {
16
ForRangeStruct(person)
17
}
18
}
19
20
func BenchmarkJsonToStruct(b *testing.B) {
21
var (
22
person = InitPerson()
23
againPersons []AgainPerson
24
)
25
data, err := json.Marshal(person)
26
if err != nil {
27
b.Fatalf("json.Marshal err: %v", err)
28
}
29
30
b.ResetTimer()
31
for i := 0; i < b.N; i++ {
32
JsonToStruct(data, againPersons)
33
}
34
}
35
36
func BenchmarkJsonIteratorToStruct(b *testing.B) {
37
var (
38
person = InitPerson()
39
againPersons []AgainPerson
40
)
41
data, err := json.Marshal(person)
42
if err != nil {
43
b.Fatalf("json.Marshal err: %v", err)
44
}
45
46
b.ResetTimer()
47
for i := 0; i < b.N; i++ {
48
JsonIteratorToStruct(data, againPersons)
49
}
50
}
Copied!

测试结果

1
BenchmarkForStruct-4 500000 3289 ns/op 0 B/op 0 allocs/op
2
BenchmarkForRangeStruct-4 200000 9178 ns/op 0 B/op 0 allocs/op
3
BenchmarkJsonToStruct-4 100 19173117 ns/op 2618509 B/op 40036 allocs/op
4
BenchmarkJsonIteratorToStruct-4 300 4116491 ns/op 3694017 B/op 30047 allocs/op
Copied!
从测试结果来看,性能排名为:for < for range < json-iterator < encoding/json。接下来我们看看是什么原因导致了这样子的排名?

性能对比

image

for-loop

在测试结果中,for range 在性能上相较 for 差。这是为什么呢?在这里我们可以参见 for range实现,伪实现如下:
1
for_temp := range
2
len_temp := len(for_temp)
3
for index_temp = 0; index_temp < len_temp; index_temp++ {
4
value_temp = for_temp[index_temp]
5
index = index_temp
6
value = value_temp
7
original body
8
}
Copied!
通过分析伪实现,可得知 for range 相较 for 多做了如下事项

Expression

1
RangeClause = [ ExpressionList "=" | IdentifierList ":=" ] "range" Expression .
Copied!
在循环开始之前会对范围表达式进行求值,多做了 “解” 表达式的动作,得到了最终的范围值

Copy

1
...
2
value_temp = for_temp[index_temp]
3
index = index_temp
4
value = value_temp
5
...
Copied!
从伪实现上可以得出,for range 始终使用值拷贝的方式来生成循环变量。通俗来讲,就是在每次循环时,都会对循环变量重新分配

小结

通过上述的分析,可得知其比 for 慢的原因是 for range 有额外的性能开销,主要为值拷贝的动作导致的性能下降。这是它慢的原因
那么其实在 for range 中,我们可以使用 _T[i] 也能达到和 for 差不多的性能。但这可能不是 for range 的设计本意了

json.Marshal/Unmarshal

encoding/json

json 互转是在三种方案中最慢的,这是为什么呢?
众所皆知,官方的 encoding/json 标准库,是通过大量反射来实现的。那么 “慢”,也是必然的。可参见下述代码:
1
...
2
func newTypeEncoder(t reflect.Type, allowAddr bool) encoderFunc {
3
...
4
switch t.Kind() {
5
case reflect.Bool:
6
return boolEncoder
7
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
8
return intEncoder
9
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, reflect.Uint64, reflect.Uintptr:
10
return uintEncoder
11
case reflect.Float32:
12
return float32Encoder
13
case reflect.Float64:
14
return float64Encoder
15
case reflect.String:
16
return stringEncoder
17
case reflect.Interface:
18
return interfaceEncoder
19
case reflect.Struct:
20
return newStructEncoder(t)
21
case reflect.Map:
22
return newMapEncoder(t)
23
case reflect.Slice:
24
return newSliceEncoder(t)
25
case reflect.Array:
26
return newArrayEncoder(t)
27
case reflect.Ptr:
28
return newPtrEncoder(t)
29
default:
30
return unsupportedTypeEncoder
31
}
32
}
Copied!
既然官方的标准库存在一定的 “问题”,那么有没有其他解决方法呢?目前在社区里,大多为两类方案。如下:
    预编译生成代码(提前确定类型),可以解决运行时的反射带来的性能开销。缺点是增加了预生成的步骤
    优化序列化的逻辑,性能达到最大化
接下来的实验,我们用第二种方案的库来测试,看看有没有改变。另外也推荐大家了解如下项目:

json-iterator/go

目前社区较常用的是 json-iterator/go,我们在测试代码中用到了它
它的用法与标准库 100% 兼容,并且性能有较大提升。我们一起粗略的看下是怎么做到的,如下:
reflect2
利用 modern-go/reflect2 减少运行时调度开销
1
...
2
type StructDescriptor struct {
3
Type reflect2.Type
4
Fields []*Binding
5
}
6
7
...
8
type Binding struct {
9
levels []int
10
Field reflect2.StructField
11
FromNames []string
12
ToNames []string
13
Encoder ValEncoder
14
Decoder ValDecoder
15
}
16
17
type Extension interface {
18
UpdateStructDescriptor(structDescriptor *StructDescriptor)
19
CreateMapKeyDecoder(typ reflect2.Type) ValDecoder
20
CreateMapKeyEncoder(typ reflect2.Type) ValEncoder
21
CreateDecoder(typ reflect2.Type) ValDecoder
22
CreateEncoder(typ reflect2.Type) ValEncoder
23
DecorateDecoder(typ reflect2.Type, decoder ValDecoder) ValDecoder
24
DecorateEncoder(typ reflect2.Type, encoder ValEncoder) ValEncoder
25
}
Copied!
struct Encoder/Decoder Cache
类型为 struct 时,只需要反射一次 Name 和 Type,会缓存 struct Encoder 和 Decoder
1
var typeDecoders = map[string]ValDecoder{}
2
var fieldDecoders = map[string]ValDecoder{}
3
var typeEncoders = map[string]ValEncoder{}
4
var fieldEncoders = map[string]ValEncoder{}
5
var extensions = []Extension{}
6
7
....
8
9
fieldNames := calcFieldNames(field.Name(), tagParts[0], tag)
10
fieldCacheKey := fmt.Sprintf("%s/%s", typ.String(), field.Name())
11
decoder := fieldDecoders[fieldCacheKey]
12
if decoder == nil {
13
decoder = decoderOfType(ctx.append(field.Name()), field.Type())
14
}
15
encoder := fieldEncoders[fieldCacheKey]
16
if encoder == nil {
17
encoder = encoderOfType(ctx.append(field.Name()), field.Type())
18
}
Copied!
文本解析优化

小结

相较于官方标准库,第三方库 json-iterator/go 在运行时上做的更好。这是它快的原因
有个需要注意的点,在 Go1.10 后 map 类型与标准库的已经没有太大的性能差异。但是,例如 struct 类型等仍然有较大的性能提高

总结

在本文中,我们首先进行了性能测试,再分析了不同方案,得知为什么了快慢的原因。那么最终在选择方案时,可以根据不同的应用场景去抉择:
    对性能开销有较高要求:选用 for,开销最小
    中规中矩:选用 for range,大对象慎用
    量小、占用小、数量可控:选用 json.Marshal/Unmarshal 的方案也可以。其重复代码少,但开销最大
在绝大多数场景中,使用哪种并没有太大的影响。但作为工程师你应当清楚其利弊。以上就是不同的方案分析概要,希望对你有所帮助 :)
Last modified 2yr ago