前言
我（@董伟明9）经常看到很多程序员， 运维在代码搜索上使用ack， 甚至ag(the_silver_searcher )， 而我工作中95%都是用grep，剩下的是ag。 我觉得很有必要聊一聊这个话题。
我以前也是一个运维， 我当时也希望找到最好的最快的工具用在工作的方方面面。 但是我很好奇为什么ag和ack没有作为linux发行版的内置部分。 内置的一直是grep。 我当初的理解是受各种开源协议的限制， 或者发行版的boss个人喜好。 后来我就做了实验， 研究了下他们到底谁快。 当时的做法也无非跑几个真实地线上log看看用时。 然后我也有了我的一个认识: 大部分时候用grep也无妨， 日志很大的时候用ag。
ack原来的域名是betterthangrep.com， 现在是beyondgrep.com。 好吧，其实我理解使用ack的同学， 也理解ack产生的原因。 这里就有个故事。
最开始我做运维使用shell， 经常做一些分析日志的工作。 那时候经常写比较复杂的shell代码实现一些特定的需求。 后来来了一位会perl的同学。 原来我写shell做一个事情， 写了20多行shell代码， 跑一次大概5分钟， 这位同学来了用perl改写， 4行， 一分钟就能跑完。 亮瞎我们的眼， 从那时候开始， 我就觉得需要学perl，以至于后来的python。
perl是天生用来文本解析的语言， ack的效率确实很高。 我想着可能是大家认为ack要更快更合适的理由吧。 其实这件事要看场景。 我为什么还用比较’土’的grep呢？
看一下这篇文章， 希望给大家点启示。不耐烦看具体测试过程的同学，可以直接看结论：
实验条件
PS: 严重声明， 本实验经个人实践， 我尽量做到合理。 大家看完觉得有异议可以试着其他的角度来做。 并和我讨论。
我使用了公司的一台开发机(gentoo)
我测试了纯英文和汉语2种， 汉语使用了结巴分词的字典，， 英语使用了miscfiles中提供的词典
# 假如你是Ubuntu: sudo apt-get install miscfiles实验前的准备
我会分成英语和汉语2种文件， 文件大小为1MB， 10MB， 100MB， 500MB， 1GB， 5GB。 没有更多是我觉得在实际业务里面不会单个日志文件过大的。 也就没有必要测试了(就算有， 可以看下面结果的趋势)。用下列程序深入测试的文件：
好吧， 效率比较低是吧？ 我自己没有vps， 公司服务器我不能没事把全部内核的cpu都占满(不是运维好几年了)。 假如你不介意htop的多核cpu飘红， 可以这样，耗时就是各文件生成的时间短板。这是生成测试文件的多进程版本：
等待一段时间后，测试的文件生成了。目录下是这样的：
确认版本实验设计
为了不产生并行执行的相互响应， 我还是选择了效率很差的同步执行， 我使用了ipython提供的%timeit。 测试程序的代码如下：
温馨提示， 这是一个灰常耗时的测试。 开始执行后 要喝很久的茶…
我来秦皇岛办事完毕(耗时超过1一天)， 继续我们的实验。
我想要的效果
我想工作的时候一般都是用到不带参数/带-i(忽略大小写)/-v(查找不匹配项)这三种。 所以这里测试了:
我先说结论
渲染图片的gist可以看这里benchmarks.ipynb。 它的数据来自上面跑的结果在序列化之后存入的文件。
grep使用简明及正则表达式
Linux下Shell编程——grep命令的基本运用
grep 命令详解及相关事例
Linux基础命令之grep详解
设置grep高亮显示匹配项
Linux grep命令学习与总结
本文永久更新链接地址：
人生最大的错误是不断担心会犯错
