为何Ruby查找含指定文本的节点比XPath快10倍？

最近做项目时需要检查HTML节点是否包含指定文本，本来想着用XPath重构代码会更简洁优雅，结果跑起来发现速度慢了整整10倍！这反差感直接给我整懵了，赶紧做了基准测试排查问题，下面是简化后的测试代码和我的分析。

基准测试代码 #

# has_keyword_benchmark.rb
require 'benchmark'
require 'nokogiri'

# 构建测试用的DOM文档
doc = Nokogiri::HTML("
<div>
  <div> A </div>
  <p> <b>A</b> </p>
  <span> B </span>
</div>")

# 用XPath实现的检查方法
def has_keywords_with_xpath(doc)
  doc.xpath('./*[contains(., "A")]').size > 0
end

# 原始的节点遍历实现方法
def has_keywords_with_traversal(doc)
  doc.children.any? do |node|
    node.text.strip.include?("A")
  end
end

# 运行基准测试，对比两种方式的性能
Benchmark.bm do |x|
  x.report("XPath方式:") { 100_000.times { has_keywords_with_xpath(doc) } }
  x.report("节点遍历方式:") { 100_000.times { has_keywords_with_traversal(doc) } }
end

为什么XPath会慢这么多？ #

我查了下Nokogiri处理XPath的逻辑，总结出几个关键原因：

• XPath表达式的全局遍历开销：contains(., "A")里的.会匹配当前节点的所有后代文本，相当于递归遍历所有子节点的文本内容，当DOM结构复杂时，这个递归过程的开销会被放大很多。
• XPath引擎的额外处理：Nokogiri需要先解析XPath表达式，构建查询语法树，再执行匹配逻辑，相比直接调用Ruby原生的遍历方法，多了好几层中间处理步骤。
• 文本合并的重复操作：虽然node.text也会合并子节点文本，但XPath的contains函数在处理时，会重复执行文本合并和匹配的逻辑，而Ruby遍历方式可以更直接地完成检查。

优化方案 #

如果想要兼顾简洁性和性能，可以试试这几种方式：

• 优化XPath表达式：如果知道目标文本所在的节点类型，可以精确指定，比如改成./div[contains(text(), "A")] | ./p[b[contains(text(), "A")]]，但这种方式通用性较差，适合固定结构的DOM。
• 优先使用原生遍历：对于简单的文本检查场景，直接用children+any?+text.include?的组合，性能会比XPath好很多，代码可读性也不差。
• 缓存文本内容：如果需要多次检查同一个节点的文本，可以先把节点的文本提前缓存起来，避免重复调用text方法生成合并文本。

内容的提问来源于stack exchange，提问作者Hirurg103