有比 string.Contains 更快的方法吗

LYL_GO · 2021-12-29 15:24:21 · 1850 次点击 · 大约8小时之前 开始浏览    置顶
这是一个创建于 2021-12-29 15:24:21 的主题,其中的信息可能已经有所发展或是发生改变。

实际应用中需要判断源字符串中是否包含子字符串,目前用的是strings.Contains,使用benchmark测试,300W字符串中找出一个符合条件的数据,strings.Contains的性能在0.0449 ns/op左右,strings.Index也差不多,在0.0429 ns/op左右;大家知道还有啥更高效的方法吗?


有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1850 次点击  
加入收藏 微博
7 回复  |  直到 2021-12-31 14:11:25
Reverie
Reverie · #1 · 3年之前

感觉不太容易,看了下string.Contains的源码,当substr比较小的时候,是暴力匹配的,做了汇编级别的优化;substr比较大的时候,就是字符串hash了

liangmanlin
liangmanlin · #2 · 3年之前

已经这么快了,还需要多快?

LYL_GO
LYL_GO · #3 · 3年之前

@Reverie 我也看了,确实比较难搞了,后面都是汇编,就是有点奇怪,benchmark测出来很快,但pprof打出来又耗时比较久,根据benchmark测出来的性能加上pprof上统计的时间算出来的调用次数远比真实业务要大很多

liangmanlin
liangmanlin · #4 · 3年之前
LYL_GOLYL_GO #3 回复

@Reverie 我也看了,确实比较难搞了,后面都是汇编,就是有点奇怪,benchmark测出来很快,但pprof打出来又耗时比较久,根据benchmark测出来的性能加上pprof上统计的时间算出来的调用次数远比真实业务要大很多

我觉得应该先说需求

jarlyyn
jarlyyn · #5 · 3年之前

我个人觉得如果你卡性能到这个程度,似乎不该使用带gc的语言了。

zzustu
zzustu · #6 · 3年之前

strings.Contains 0.0449 ns/op 难道还不够快吗?我的Benchmark里面什么逻辑都不写,也被甩了将近十倍的差距。啥配置这么强悍?

func BenchmarkNoop(b *testing.B) {
    for i := 0; i < b.N; i++ {
    }
}

// goos: linux
// goarch: amd64
// pkg: xxx.com/xxx
// cpu: Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
// BenchmarkNoop
// BenchmarkNoop-6       1000000000             0.2599 ns/op
// PASS
lysShub
lysShub · #7 · 3年之前

可以明确的告诉你,你的benchmark很可能写错了,因为不可能那么快

添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传