[Golang]字符串拼接方式的性能分析
本文100%由本人(Haoxiang Ma)原创,如需转载请注明出处。
本文写于2019/02/16,基于
Go 1.11
。
至于其他版本的Go SDK,如有出入请自行查阅其他资料。
Overview
写本文的动机来源于Golang中文社区里一篇有头没尾的帖子《Go语言字符串高效拼接》,里面只提了Golang里面字符串拼接的几种方式,但是在最后却不讲每种方式的性能,也没有给出任何的best practice。本着无聊 + 好奇心,就决定自行写benchmark来测试,再对结果和源码进行分析,试图给出我认为的best practice吧。
性能测试
根据帖子里的内容,在Golang
里有5种字符串拼接的方式:
直接+号拼接
func (strs []string) string {
s := ""
for _, str := range strs {
s += str
}
return s
}fmt.Sprint()拼接
// fmt拼接
func ConcatWithFmt(strs []string) string {
s := fmt.Sprint(strs)
return s
}strings.Join()拼接
// strings.Join拼接
func ConcatWithJoin(strs []string) string {
s := strings.Join(strs, "")
return s
}Buffer拼接
// bytes.Buffer拼接
func ConcatWithBuffer(strs []string) string {
buf := bytes.Buffer{}
for _, str := range strs {
buf.WriteString(str)
}
return buf.String()
}Builder拼接
// strings.Builder拼接
func ConcatWithBuilder(strs []string) string {
builder := strings.Builder{}
for _, str := range strs {
builder.WriteString(str)
}
return builder.String()
}
为了测试各自的性能,就用Golang
自带test模块的benchmark来进行测试。
在测试中,分3组数据,5组测试,即一共3 * 5 = 15次独立测试。其中3组数据是指:
- size = 10K的字符串数组,每个元素均为
"hello"
- size = 50K的字符串数组,每个元素均为
"hello"
- size = 100K的字符串数组,每个元素均为
"hello"
5组测试是指:
- 直接+号拼接,要跑10K、50K、100K的数据
- fmt.Sprint()拼接,要跑10K、50K、100K的数据
- strings.Join()拼接,要跑10K、50K、100K的数据
- Buffer拼接,要跑10K、50K、100K的数据
- Builder拼接,要跑10K、50K、100K的数据
Benchmark代码如下:
package main import ( |
经过测试(go test -bench=. -benchmem
),结果如下:
...... |
可以看出
- 运行速度上,Builder、Buffer、Join的速度属于同一数量级,绝对值也差不了太多;fmt要比它们一个数量级;直接+号拼接是最慢的。
- 内存分配上,Join表现最优秀,Buffer次之,Builder第三;而fmt和直接+号拼接最差,要执行很多次内存分配操作。
源码分析
速度&内存分配都很优秀的
strings.Join()
func Join(a []string, sep string) string {
// 专门为短数组拼接做的优化
// 详情查阅golang.org/issue/6714
switch len(a) {
case 0:
return ""
case 1:
return a[0]
case 2:
return a[0] + sep + a[1]
case 3:
return a[0] + sep + a[1] + sep + a[2]
} // 计算总共要插入多长的分隔符,n = 分隔符总长
n := len(sep) * (len(a) - 1) // 遍历待拼接的数组,逐个叠加字符串的长度
// 最后n = 分隔符总长 + 所有字符串的总长 = 拼接结果的总长
for i := 0; i < len(a); i++ {
n += len(a[i])
} // 一次性分配n byte的内存空间,并且把第一个字符串拷贝到slice的头部
b := make([]byte, n)
bp := copy(b, a[0]) // 从下标为1开始,调用原生的copy函数
// 逐个把分隔符&字符串拷贝到slice里对应的位置
for _, s := range a[1:] {
bp += copy(b[bp:], sep)
bp += copy(b[bp:], s)
} // 最后将byte slice强转为string,返回
return string(b)
}可以看出
strings.Join()
为什么表现如此优秀,主要原因是只有1次的显式内存分配(b := make([]byte, n)
)和1次隐式内存分配(return string(b)
),不需要在拼接过程中反复多次分配内存,挪动内存里的数据,减少了很多内存管理的消耗。略差一筹的
bytes.Buffer.WriteString()
// 尝试扩容n个单位
func (b *Buffer) tryGrowByReslice(n int) (int, bool) {
// 如果底层slice的剩余空间 >= n个单位,就不需要重新分配内存
// 而是reslice,把底层slice的cap限定在l + n
if l := len(b.buf); n <= cap(b.buf)-l {
b.buf = b.buf[:l+n]
return l, true
} // 如果底层slice的剩余空间不足n个单位,放弃reslice
// 说明需要重新分配内存,而不是reslice那么简单了
return 0, false
} // 扩容n个单位
func (b *Buffer) grow(n int) int {
m := b.Len() // 边界情况,空slice,先把一些属性reset掉
if m == 0 && b.off != 0 {
b.Reset()
} // 先试试不真正分配空间,通过reslice来“扩容”
if i, ok := b.tryGrowByReslice(n); ok {
return i
} // bootstrap是一个长度为64的slice,在buffer对象初始化时,
// bootstrap就已经分配好了,如果n小于bootstrap长度,
// 可以利用bootstrap slice来reslice,不需要重新分配内存空间
if b.buf == nil && n <= len(b.bootstrap) {
b.buf = b.bootstrap[:n]
return 0
} // 上述几种情况都无法满足
c := cap(b.buf)
if n <= c/2-m {
// 理解为m + n <= c/2比较好
// 如果扩容后的长度(m + n)比c/2要小,说明当前还有一大堆可用的空间
// 直接reslice,以b.off打头
copy(b.buf, b.buf[b.off:])
} else if c > maxInt-c-n {
// c + c + n > maxInt,申请扩容n个单位太多了,不可接受
panic(ErrTooLarge)
} else {
// 当前剩余的空间不太够了,重新分配内存,长度为c + c + n
buf := makeSlice(2*c + n)
copy(buf, b.buf[b.off:])
b.buf = buf
}
// Restore b.off and len(b.buf).
b.off = 0
b.buf = b.buf[:m+n]
return m
} // 拼接的方法
func (b *Buffer) WriteString(s string) (n int, err error) {
b.lastRead = opInvalid // 先尝试reslice得到len(s)个单位的空间
m, ok := b.tryGrowByReslice(len(s))
if !ok {
// 无法通过reslice得到空间,直接粗暴地申请grow
m = b.grow(len(s))
}
return copy(b.buf[m:], s), nil
}为什么
bytes.Buffer.WriteString()
性能比Join差呢,其实也是内存分配策略惹的祸。在Join里只有两次内存空间申请的操作,而Buffer
里可能会有很多次。具体来说就是buf := makeSlice(2*c + n)
这一句,每次重申请只申请2 * c + n
的空间,用完了就要再申请2 * c + n
。当拼接的数据项很多,每次申请的空间也就2 * c + n
,很快就用完了,又要再重新申请,所以造成了性能不是很高。略差一筹的
strings.Builder()
func (b *Builder) WriteString(s string) (int, error) {
b.copyCheck()
b.buf = append(b.buf, s...)
return len(s), nil
}代码很简洁,就是最直白的slice append,一时append一时爽,一直append一直爽。所以当底层slice的可用空间不足,就会在append里一直申请新的内存空间。跟
bytes.Buffer
不同的是,这里并没有自己管理“扩容”的逻辑,而是交由原生的append函数去管理。最差劲的
fmt.Sprint()
type buffer []byte type pp struct {
buf buffer
......
} func Sprint(a ...interface{}) string {
p := newPrinter()
p.doPrint(a)
s := string(p.buf)
p.free()
return s
}printer
里的核心数据结构就是buf
,而buf
其实就是一个[]byte
,所以给buf
不停地拼接字符串,空间不够了又继续开辟新的内存空间,所以性能低下。
总结
实际上,只有当拼接的字符串非常非常多的时候,才需要纠结性能。像本文里动辄拼接10K、50K、100K个字符串的情况在实际业务中应该是很少很少的。
如果实在要纠结性能,参考以下几点
- Join的速度最好,但是不至于完爆Builder和Buffer。三者的速度属于同一数量级。fmt和直接+号拼接速度最慢。
- Join的内存分配策略最好,内存分配次数最少;Builder和Buffer的内存分配策略还算可以,类似于线性增长;fmt和直接+号拼接的内存分配策略最差。
[Golang]字符串拼接方式的性能分析的更多相关文章
- Lua大量字符串拼接方式效率对比及原因分析
Lua大量字符串拼接方式效率对比及原因分析_AaronChan的博客-CSDN博客_lua字符串拼接消耗 https://blog.csdn.net/qq_26958473/article/detai ...
- JS几种变量交换方式以及性能分析对比
前言 "两个变量之间的值得交换",这是一个经典的话题,现在也有了很多的成熟解决方案,本文主要是列举几种常用的方案,进行大量计算并分析对比. 起由 最近做某个项目时,其中有一个需求是 ...
- JS几种数组遍历方式以及性能分析对比
前言 这一篇与上一篇 JS几种变量交换方式以及性能分析对比 属于同一个系列,本文继续分析JS中几种常用的数组遍历方式以及各自的性能对比 起由 在上一次分析了JS几种常用变量交换方式以及各自性能后,觉得 ...
- Java中测试StringBuilder、StringBuffer、String在字符串拼接上的性能
应一个大量字符串拼接的任务 测试一下StringBuilder.StringBuffer.String在操作字符串拼接时候的性能 性能上理论是StringBuilder > StringBu ...
- 【转】Java 5种字符串拼接方式性能比较。
最近写一个东东,可能会考虑到字符串拼接,想了几种方法,但对性能未知,于是用Junit写了个单元测试. 代码如下: import java.util.ArrayList; import java.uti ...
- Java 5种字符串拼接方式性能比较。
最近写一个东东,可能会考虑到字符串拼接,想了几种方法,但对性能未知,于是用Junit写了个单元测试. 代码如下: import java.util.ArrayList; import java.uti ...
- Java 5种字符串拼接方式性能比较
http://blog.csdn.net/kimsoft/article/details/3353849 import java.util.ArrayList; import java.util.Li ...
- golang字符串拼接性能对比
对比 +(运算符).strings.Join.sprintf.bytes.Buffer对字符串拼接的性能 package main import ( "bytes" "f ...
- Java 字符串拼接方式
import java.util.ArrayList; import java.util.List; import org.apache.commons.lang.StringUtils; impor ...
随机推荐
- 测试Java程序执行耗费的时间
package test; public class Main { public static void main(String[] args) { long start = System.curre ...
- c++语法(1)
#include<iostream> #include<windows.h> using namespace std; class Parents { public: ; // ...
- POJ 1O17 Packets [贪心]
Packets Description A factory produces products packed in square packets of the same height h and of ...
- Ubuntu目錄
/ (这就是著名的根)├── bin (你在终端运行的大多数程序,比如cp.mv...)├── boot (内核放在这里,这个目录也经常被作为某个独立分 ...
- 获取IP和IP地址
<script src="http://pv.sohu.com/cityjson?ie=utf-8"></script>; <script type= ...
- 4.windows-oracle实战第四课 -表的查询
所有语句均为安装oracle数据库后scott的默认表emp,dept等表 1.自己插入自己:insert into 表名 (字段)select *from 表名 2.去除重复行: select di ...
- 安装R的h5包
系统 redhat7 安装H5的包, 依赖系统hdf5包,如下安装完, 发现版本不一致, sudo yum install hdf5-devel 解决办法: 移花接木 sudo ln -s /opt/ ...
- 吴裕雄--天生自然 PYTHON3开发学习:XML 解析
<collection shelf="New Arrivals"> <movie title="Enemy Behind"> <t ...
- 第04项目:淘淘商城(SpringMVC+Spring+Mybatis)【第八天】(solr服务器搭建、搜索功能实现)
https://pan.baidu.com/s/1bptYGAb#list/path=%2F&parentPath=%2Fsharelink389619878-229862621083040 ...
- “全隐藏式3D摄像头”亮相,FindX如何将设计与体验融为一体
北京时间6月20日,OPPO在卢浮宫发布暌违四年之久的Find旗舰系列新手机--Find X.在Find X背后,我认为其设计值得深思.尤其是Find X为突破传统设计束缚,首创双轨潜望结构有着重要启 ...