Go 性能分析之案例一

Wesley13
• 阅读 630

思考

相信大家在实际的项目开发中会遇到这么一个事,有的程序员写的代码不仅bug少,而且性能高;而有的程序员写的代码能否流畅的跑起来,都是一个很大问题。
而我们今天要讨论的就是一个关于性能优化的案例分析。

案例分析

我们先来构造一些基础数据(长度为10亿的切片,并赋上值):

var testData = GenerateData()

// generate billion slice data
func GenerateData() []int {
    data := make([]int, 1000000000)
    for key, _ := range data {
        data[key] = key % 128
    }

    return data
}

// get length
func GetDataLen() int {
    return len(testData)
}

案例一

// case one
func CaseSumOne(result *int) {
    data := GenerateData()
    for i := 0; i < GetDataLen(); i++ {
        *result += data[i]
    }
}
// case two
func CaseSumTwo(result *int) {
    data := GenerateData()
    dataLen := GetDataLen()
    for i := 0; i < dataLen; i++ {
        *result += data[i]
    }
}

执行结果

$ go test -bench=.
goos: windows
goarch: amd64
BenchmarkCaseSumOne-8                  1        7439749000 ns/op
BenchmarkCaseSumTwo-8                  1        2529266700 ns/op
PASS
ok      _/C_/go-code/perform/case-one   14.059s

问题分析

  • CaseSumTwo执行效率是CaseSumOne的2.94倍,快了近三倍,这是为什么呢?
  • 我想这个其实很容易猜到,这里有一个连续的函数调用“GetDataLen()”,

我们来看下两个函数的汇编,做个简单的对比:

函数CaseSumOne

"".CaseSumOne STEXT size=83 args=0x4 locals=0xc
        0x0000 00000 (point.go:22)      TEXT    "".CaseSumOne(SB), $12-4
        ...
        // point.go:24 -> for i := 0; i < GetDataLen(); i++ 
        0x0021 00033 (point.go:24)      PCDATA  $2, $2
        0x0021 00033 (point.go:24)      PCDATA  $0, $1
        0x0021 00033 (point.go:24)      MOVL    "".result+16(SP), DX 
        0x0025 00037 (point.go:24)      XORL    BX, BX
        0x0027 00039 (point.go:24)      JMP     47
        0x0029 00041 (point.go:25)      MOVL    (CX)(BX*4), BP    // CX循环计数器
        0x002c 00044 (point.go:25)      ADDL    BP, (DX)
        0x002e 00046 (point.go:24)      INCL    BX // i++
        0x002f 00047 (point.go:24)      MOVL    "".testData+4(SB), BP // 栈指针寄存器
        0x0035 00053 (point.go:24)      CMPL    BX, BP
        0x0037 00055 (point.go:24)      JGE     65
        ...
        0x0045 00069 (point.go:25)      CALL    runtime.panicindex(SB)
        0x004c 00076 (point.go:22)      CALL    runtime.morestack_noctxt(SB)
        ...

函数CaseSumTwo

"".CaseSumTwo STEXT size=83 args=0x4 locals=0xc
        0x0000 00000 (point.go:30)      TEXT    "".CaseSumTwo(SB), $12-4
        ...
        // point.go:32 -> dataLen := GetDataLen()
        // point.go:33 -> for i := 0; i < dataLen; i++ {
        0x0021 00033 (point.go:32)      MOVL    "".testData+4(SB), DX
        0x0027 00039 (point.go:33)      PCDATA  $2, $2
        0x0027 00039 (point.go:33)      PCDATA  $0, $1
        0x0027 00039 (point.go:33)      MOVL    "".result+16(SP), BX
        0x002b 00043 (point.go:33)      XORL    BP, BP
        0x002d 00045 (point.go:33)      JMP     53
        0x002f 00047 (point.go:34)      MOVL    (AX)(BP*4), SI
        0x0032 00050 (point.go:34)      ADDL    SI, (BX)
        0x0034 00052 (point.go:33)      INCL    BP
        0x0035 00053 (point.go:33)      CMPL    BP, DX
        0x0037 00055 (point.go:33)      JGE     65
        ...
        0x0045 00069 (point.go:34)      CALL    runtime.panicindex(SB)
        0x004c 00076 (point.go:30)      CALL    runtime.morestack_noctxt(SB)
        ...

比较结论

不难发现主要的区别是在CaseSumOne中多了这么一行:

0x002f 00047 (point.go:24) MOVL "".testData+4(SB), BP

其实虽然只有一行,但是对于函数“GetDataLen”里需要调用的指令对CPU的消耗:

"".GetDataLen STEXT size=36 args=0x4 locals=0x0
        0x0000 00000 (point.go:17)      TEXT    "".GetDataLen(SB), $0-4 // 
        0x0000 00000 (point.go:17)      MOVL    TLS, CX
        0x0007 00007 (point.go:17)      MOVL    (CX)(TLS*2), CX
        0x000d 00013 (point.go:17)      CMPL    SP, 8(CX)
        0x0010 00016 (point.go:17)      JLS     29
        0x0012 00018 (point.go:17)      FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0012 00018 (point.go:17)      FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0012 00018 (point.go:17)      FUNCDATA        $3, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0012 00018 (point.go:18)      PCDATA  $2, $0
        0x0012 00018 (point.go:18)      PCDATA  $0, $0
        0x0012 00018 (point.go:18)      MOVL    "".testData+4(SB), AX // 寄存器寻址 AX = lenVAL
        0x0018 00024 (point.go:18)      MOVL    AX, "".~r0+4(SP)    // SP = AX = lenVal
        0x001c 00028 (point.go:18)      RET
        0x001d 00029 (point.go:18)      NOP
        0x001d 00029 (point.go:17)      PCDATA  $0, $-1
        0x001d 00029 (point.go:17)      PCDATA  $2, $-1
        0x001d 00029 (point.go:17)      CALL    runtime.morestack_noctxt(SB)    // 压栈
        ...

虽然,看似小小一行代码的区别,但是在指令级的角度上,进行了创建栈空间、压栈、寻址、赋值等一系列操作,况且这里进行了循环调用。

案例二

// case two
func CaseSumTwo(result *int) {
    data := GenerateData()
    dataLen := GetDataLen()
    for i := 0; i < dataLen; i++ {
        *result += data[i]
    }
}
// case three
func CaseSumThree(result *int) {
    data := GenerateData()
    dataLen := GetDataLen()
    tmp := *result
    for i:= 0; i < dataLen; i++ {
        tmp += data[i]
    }
    *result = tmp
}

执行结果

$ go test -bench=.
goos: windows
goarch: amd64
BenchmarkCaseSumTwo-8                  1        2529266700 ns/op
BenchmarkCaseSumThree-8                1        1657554600 ns/op
PASS
ok      _/C_/go-code/perform/case-one   8.2773

问题分析

  • 虽然对连续函数调用进行了优化,但是CaseSumThree对执行效率还是高于CaseSumTwo1.52倍,还有哪些情况会影响执行性能呢?

我们再来对比下“CaseSumTwo”和“CaseSumThree”对汇编源码:

函数CaseSumTwo

"".CaseSumTwo STEXT size=83 args=0x4 locals=0xc
        0x0000 00000 (point.go:30)      TEXT    "".CaseSumTwo(SB), $12-4
        ...
        // point.go:31 -> data := GenerateData()
        // point.go:34 -> *result += data[i] 
        0x001a 00026 (point.go:31)      MOVL    (SP), AX
        0x0027 00039 (point.go:33)      MOVL    "".result+16(SP), BX
        0x002f 00047 (point.go:34)      MOVL    (AX)(BP*4), SI // 栈寄存器移动四个字节, -> SI源变址寄存器
        0x0032 00050 (point.go:34)      ADDL    SI, (BX)  // SI
        0x0034 00052 (point.go:33)      INCL    BP
        0x0035 00053 (point.go:33)      CMPL    BP, DX
        0x0037 00055 (point.go:33)      JGE     65
        0x0039 00057 (point.go:34)      TESTB   AX, (BX)
        0x003b 00059 (point.go:34)      CMPL    BP, CX
        0x003d 00061 (point.go:34)      JCS     47
        0x003f 00063 (point.go:34)      JMP     69
        0x0041 00065 (<unknown line number>)    PCDATA  $2, $-2
        0x0041 00065 (<unknown line number>)    PCDATA  $0, $-2
        0x0041 00065 (<unknown line number>)    ADDL    $12, SP
        0x0044 00068 (<unknown line number>)    RET
        0x0045 00069 (point.go:34)      PCDATA  $2, $0
        0x0045 00069 (point.go:34)      PCDATA  $0, $1
        0x0045 00069 (point.go:34)      CALL    runtime.panicindex(SB)
        0x004a 00074 (point.go:34)      UNDEF
        0x004c 00076 (point.go:34)      NOP

函数CaseSumThree

"".CaseSumThree STEXT size=97 args=0x4 locals=0x10
        0x0000 00000 (point.go:39)      TEXT    "".CaseSumThree(SB), $16-4
        ...
        // point.go:40 -> data := GenerateData()
        // point.go:42 -> tmp := *result
        // point.go:44 -> tmp += data[i]
        // point.go:46 -> *result = tmp
        0x001a 00026 (point.go:40)      MOVL    (SP), AX
        0x0021 00033 (point.go:42)      PCDATA  $2, $2
        0x0021 00033 (point.go:42)      PCDATA  $0, $1
        0x0021 00033 (point.go:42)      MOVL    "".result+20(SP), DX
        0x0025 00037 (point.go:42)      MOVL    (DX), BX // ->BX数据指针寄存器
        0x0027 00039 (point.go:41)      MOVL    "".testData+4(SB), BP
        0x002d 00045 (point.go:41)      XORL    SI, SI
        0x002f 00047 (point.go:43)      JMP     67
        0x0031 00049 (point.go:43)      LEAL    1(SI), DI
        0x0034 00052 (point.go:43)      MOVL    DI, "".i+12(SP) // 移动DI到栈指针12字节的位置
        0x0038 00056 (point.go:44)      MOVL    (AX)(SI*4), DI // 源变址寄存器移动四个字节(32位),-> 目的变址寄存器
        0x003b 00059 (point.go:44)      ADDL    DI, BX // DI+BX
        0x003d 00061 (point.go:43)      MOVL    "".i+12(SP), DI 
        0x0041 00065 (point.go:43)      MOVL    DI, SI
        0x0043 00067 (point.go:43)      CMPL    SI, BP
        0x0045 00069 (point.go:43)      JGE     77
        0x0047 00071 (point.go:44)      CMPL    SI, CX
        0x0049 00073 (point.go:44)      JCS     49
        0x004b 00075 (point.go:44)      JMP     83
        0x004d 00077 (point.go:46)      PCDATA  $2, $0
        0x004d 00077 (point.go:46)      MOVL    BX, (DX)
        0x004f 00079 (point.go:47)      ADDL    $16, SP
        0x0052 00082 (point.go:47)      RET
        0x0053 00083 (point.go:44)      CALL    runtime.panicindex(SB)
        ...

比较结论

CaseSumTwo函数,在进行ADDL之前,因为“*result”为指针变量,所以不能直接与data[i]运算。因此需要创建一个栈空间,并指向data的地址并,然后通过移动栈指针后得到下一个值的地址,并赋与SI。
CaseSumThree函数,在进行ADDL执行前,创建了一个值变量,那么在执行ADDL的时候,只需要移动SI获取下一个data的值就可以直接进行算数运算,中间少了地址的引用的栈的操作。

堆和栈

其实说白了,就是CaseSumTwo中 *result内存是分配在堆上的,而 CaseSumThree中 tmp是分配在栈上的,而堆和栈堆性能区别这里做一个简单堆比较:

  1. 有寄存器直接对栈进行访问(esp,ebp),而对堆访问,只能是间接寻址。 也就是说,可以直接从地址取数据放至目标地址;使用堆时,第一步将分配的地址放到寄存器,然后取出这个地址的值,然后放到目标地址。

  2. 栈中数据cpu命中率更高,满足局部性原理。

  3. 栈是编译时系统自动分配空间,而堆是动态分配(运行时分配空间),所以栈的速度快。

  4. 栈是先进后出的队列结构,比堆结构相对简单,分配速度大于堆。

总结

本章主要讲了三个点:

  1. 消除循环的低效率
  2. 减少过程调用
  3. 消除不必要的内存引用

引用《深入计算机系统原理》一书中对性能优化所提到的三个方面:

  1. 高级设计,为遇到的问题选择适当的算法和数据结构。要特别警觉,避免使用那些会渐进地产生糟糕性能的算法或编码技术。
  2. 基本编码原则,从指令的角度考虑,开发中应如何编码,才能减少执行的指令。
  3. 低级优化,针对现代处理器,如何让cpu的流水线尽量饱合。

所以,一个优秀的程序员在写每一行代码,定义每一个变量,也许背后思考的就会更多。

原文地址

https://github.com/WilburXu/blog/blob/master/Golang/Go%20%E6%80%A7%E8%83%BD%E5%88%86%E6%9E%90%E4%B9%8B%E6%A1%88%E4%BE%8B%E4%B8%80.md

点赞
收藏
评论区
推荐文章
Irene181 Irene181
3年前
手把手教你用Python网络爬虫实现起点小说下载
今天要跟大家分享一个小说爬取案例起点小说的小说下载。在做这个案例之前,我们需要对其进行分析,1.界面分析,如图:通过分析很容易就找到了我们的get请求参数,然后获取相应页面的小说名和链接:获取到数据之后,我们就随机挑选一篇小说来进行下载,我们选第一篇,然后打开它的文章目录,可以看到是这样的,如图:基本上这篇小说很长,可以看到它卷一和卷二是免费的,后面的收费,
Wesley13 Wesley13
3年前
Java本地缓存框架系列
Caffeine是一个基于Java8的高性能本地缓存框架,其结构和GuavaCache基本一样,api也一样,基本上很容易就能替换。Caffeine实际上就是在GuavaCache的基础上,利用了一些Java8的新特性,提高了某些场景下的性能效率。这一章节我们会从Caffeine的使用引入,并提出一些问题,之后分析其源代码解
Stella981 Stella981
3年前
Android app native代码性能分析
分析我们app中native层的C/C代码性能,能够方便我们找出其中的性能瓶颈,并在稍后做有针对性的优化。1\.下载androidndkprofiler工欲善其事,必先利其器,我们先要有良好的工具来支持我们做性能分析的愿望。androidndkprofiler就是目前我们可用的比较好
Wesley13 Wesley13
3年前
mySql索引优化分析
MySQL索引优化分析为什么你写的sql查询慢?为什么你建的索引常失效?通过本章内容,你将学会MySQL性能下降的原因,索引的简介,索引创建的原则,explain命令的使用,以及explain输出字段的意义。助你了解索引,分析索引,使用索引,从而写出更高性能的sql语句。还在等啥子?撸起袖子就是干!案例分析我们先
Stella981 Stella981
3年前
Node.js 应用故障排查手册 —— 类死循环导致进程阻塞
类死循环导致进程阻塞楔子在实践篇一中我们看到了两个表象都是和CPU相关的生产问题,它们基本也是我们在线上可能遇到的这一类问题的典型案例,而实际上这两个案例也存在一个共同点:我们可以通过 Node.js性能平台(https://www.oschina.net/action/GoToLink?urlhttps%3A
Easter79 Easter79
3年前
ThreadLocal 内存泄露的实例分析
前言之前写了一篇深入分析ThreadLocal内存泄漏问题(https://my.oschina.net/thinwonton/blog/1505136)是从理论上分析ThreadLocal的内存泄漏问题,这一篇文章我们来分析一下实际的内存泄漏案例。分析问题的过程比结果更重要,理论结合实际才能彻底分析出内存泄漏的原因。案例与分析
Stella981 Stella981
3年前
Redis企业级应用
   我们在做项目的时候经常会遇到很多性能的问题,也成为整个系统优化最疼痛的问题,主要还是因为在用户量大的时候或者就是说高并发访问的时候,我们系统的数据库会有一个限制。当然也可以通过对数据库的优化对系统进行优化,(最常见的数据库优化手段无非就是建索引,explain分析慢sql,以及sql语句的优化或者分库分表等一系列的策略,当然后面我会专门写一篇文章专
【ChatGPT应用篇】助力Beauty代码的初体验 | 京东云技术团队
思考过程:案例1:项目里面有Excel文件的解析场景,试着与ChatGPT进行了交互,现将问题整理如下:1.给我写一个Java版本的excel导入解析代码(毫不客气的分配任务)2.需要支持100000000数据量(业务需求变更)3.优化代码需要支持1000
京东云开发者 京东云开发者
12个月前
大数据从业者必知必会的Hive SQL调优技巧 | 京东云技术团队
摘要:在大数据领域中,HiveSQL被广泛应用于数据仓库的数据查询和分析。然而,由于数据量庞大和复杂的查询需求,HiveSQL查询的性能往往不尽人意。本文针对HiveSQL的性能优化进行深入研究,提出了一系列可行的调优方案,并给出了相应的优化案例和优化前后
京东云开发者 京东云开发者
8个月前
一次接口的性能优化之旅
一、引言在项目开发过程中,我们经常会遇到接口响应慢的问题。这不仅影响了用户体验,还可能降低了系统的吞吐量。为了提高接口性能,我们需要对整个系统进行全面的优化,包括代码层面、数据库、缓存、异步处理等方面。本文将分享一个接口性能优化之旅,希望能帮助大家掌握Pf