工具与资源blog.burntsushi.net
ripgrep：一款新的命令行搜索工具
Ripgrep – A new command line search tool
2016 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 ripgrep（rg）的发布博文：一款用 Rust 编写的命令行搜索工具，目标是兼顾 grep 的速度与 ack/ag 的易用性。作者详细对比了 GNU grep、ag、ack、pt 等工具在不同场景下的表现与取舍，解释了 ripgrep 通过 Rust regex 引擎、默认不计数行号、避免 mmap 等设计获得性能优势。
为什么经久不衰：它既是 ripgrep 的诞生宣言，也是一篇关于工具设计权衡（默认值、正则引擎、IO 策略）的经典技术写作，多年后仍是理解现代搜索工具的必读材料。
HN 评论精选
作者的技术背景让工具可信，博文本身也是高质量技术写作的典范
本来以为是又一个 grep 替代品……但一看是 burntsushi 写的就来劲了。他是 Rust 正则库的作者，那个库相当精巧。抛开工具本身，这篇博文也应该成为 Hacker News 发帖的黄金标准：详尽、有技术深度、有趣。
losvedir查看英文原文
Meh, yet another grep tool.... wait, by burntsushi! Whenever I hear of someone wanting to improve grep I think of the classic ridiculous fish piece[0]. But when I saw that this one was by the author of rust's regex tools, which I know from a previous post on here, are quite sophisticated, I perked up. Also, the tool aside, this blog post should be held up as the gold standard of what gets posted to hacker news: detailed, technical, interesting. Thanks for your hard work! Looking forward to taking this for a spin. [0] http://ridiculousfish.com/blog/posts/old-age-and-treachery.html
ag 作者认可对比的公正性，并剖析了 ripgrep 更快的三个技术原因
我是 ag 的作者。这是对各代码搜索工具非常好的一份对比，作者准确展示了每个工具在特定场景下的失误和性能短板，关于默认值重要性的观点也完全正确。ripgrep 相对 ag 的提速主要来自：只支持可编译为 DFA 的 Rust 正则（ag 因用户依赖完整 PCRE 而受限）、默认不计数行号、不使用 mmap()。
ggreer查看英文原文
I'm the author of ag. That was a really good comparison of the different code searching tools. The author did a great job of showing how each tool misbehaved or performed poorly in certain circumstances. He's also totally right about defaults mattering. It looks like ripgrep gets most of its speedup on ag by: 1. Only supporting DFA-able Rust regexes. I'd love to use a lighter-weight regex library in ag, but users are accustomed to full PCRE support. Switching would cause me to receive a lot of angry emails. Maybe I'll do it anyway. PCRE has some annoying limitations. (For example, it can only search up to 2GB at a time.) 2. Not counting line numbers by default. The blog post addresses this, but I think results without line numbers are far less useful; so much so that I've traded away performance in ag. (Note that even if you tell ag not to print line numbers, it still wastes time counting them. The printing code is the result of me merging a lot of PRs that I really shouldn't have.) 3. Not using mmap(). This is a big one, and I'm not sure what the deal is here. I just added a --nommap option to ag in master.[1] It's a naive implementation, but it benchmarks comparably to the default mmap() behavior. I'm really hoping there's a flag I can pass to mmap() or madvise() that says, "Don't worry about all that synchronization stuff. I just want to read these bytes sequentially. I'm OK with undefined behavior if something else changes the file while I'm reading it." The author also points out correctness issues with ag. Ag doesn't fully support .gitiginore. It doesn't support unicode. Inverse matching (-v) can be crazy slow. These shortcomings are mostly because I originally wrote ag for myself. If I didn't use certain gitignore rules or non-ASCII encodings, I didn't write the code to support them. Some expectation management: If you try out ripgrep, don't get your hopes up. Unless you're searching some really big codebases, you won't notice the speed difference. What you will notice, however, are the feature differences. Take a look at https://github.com/BurntSushi/ripgrep/issues to get a taste of what's missing or broken. It will be some time before all those little details are ironed-out. That said, may the best code searching tool win. :) 1. https://github.com/ggreer/the_silver_searcher/commit/bd65e2691d6ce673e026842d7e7d02bc25adfd26
指出博文对 glibc memchr 实现的描述有误
文中说 GNU grep 的 memchr 是标准 C 代码、靠自动向量化使用 SIMD，我认为这不正确：glibc 在 x86_64 上有手写的架构专用汇编版 memchr。
minimax查看英文原文
In contrast, GNU grep uses libc’s memchr, which is standard C code with no explicit use of SIMD instructions. However, that C code will be autovectorized to use xmm registers and SIMD instructions, which are half the size of ymm registers. I don't think this is correct. glibc has architecture specific hand rolled (or unrolled if you will lol) assembly for x64 memchr. See here: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/memrchr.S;h=840de30cd71ba96b3ae43540e6ac255c28906cc5;hb=HEAD
提醒大家磁盘 IO 才是搜索性能的真正瓶颈，值得针对性优化
希望更多人真正去优化磁盘 IO。我的源码树可能在缓存里，但日志、/usr/share/docs、旧项目肯定不在。btrfs 的 Chris Mason 做过按磁盘顺序遍历读取文件的概念验证，展示了可观的潜在收益。
cwillu查看英文原文
I wish more people actually took steps to optimize disk io though; my current source tree may be in cache, but my logs certainly aren't. Nor are my /usr/share/docs/, /usr/includes/, or my old projects. Chris Mason of btrfs fame did some proof of concept work for walking and reading trees in on-disk order, showing some pretty spectacular potential gains: https://oss.oracle.com/~mason/acp/ Tooling to do your own testing: https://oss.oracle.com/~mason/seekwatcher/
历次讨论
同类还值得读
直接在浏览器中启动 Linux 内核
Boot a linux kernel right inside your browser.
Fabrice Bellard 的 JSLinux 页面，用 JavaScript 在浏览器里启动一个 Linux 内核，并提供一个可交互的终端环境。
工具与资源上首页 5 次 · 2011–2025bellard.orgHacker News 未公开功能与行为清单（2018）
A List of Hacker News's Undocumented Features and Behaviors (2018)
数据科学家 Max Woolf 整理的 Hacker News 未公开功能与行为清单，涵盖投票机制、排名算法、账号惩罚等社区运作细节。
工具与资源上首页 5 次 · 2019–2025github.comMapSCII：在终端中用盲文和 ASCII 渲染地图
MapSCII – Braille and ASCII map renderer for the console
MapSCII 是一个在命令行终端里渲染地图的开源工具，用盲文字符和 ASCII 字符把地理数据画成可交互浏览的字符地图。
工具与资源上首页 5 次 · 2017–2025github.com顶尖大学的免费在线课程
Free Online Courses from Top Universities
Open Culture 整理的一份免费在线课程合集，汇集了全球顶尖大学（如 MIT、斯坦福、耶鲁等）向公众开放的网络课程资源，涵盖音频、视频等多种形式。
工具与资源上首页 5 次 · 2010–2022openculture.com淘气字符串：容易引发用户输入问题的字符串清单
Naughty Strings: A list of strings likely to cause issues as user-input data
一个 GitHub 仓库，收录了大量容易让程序出问题的用户输入字符串，如特殊字符、emoji、SQL 注入片段、系统命令等，供开发者用于测试输入处理逻辑。
工具与资源上首页 4 次 · 2015–2020github.com