Ruby 2.4：如何加速动态初始化正则以适配.match?方法

这是个典型的正则性能陷阱——问题根本不在match?方法本身，而是你重复编译正则的操作吃掉了所有性能优势！让我一步步拆解原因和解决办法：

性能差异的核心原因 #

Ruby的正则表达式有个关键特性：首次编译后会被缓存复用，但你用字符串插值/#{reg_str}/i的方式创建正则时，Ruby无法判断每次插值后的字符串是否完全相同，所以每次循环都会重新编译一遍正则。

编译复杂正则本身就是非常耗时的操作——看你的测试数据就很明显：

• 直接写死正则的match?：只编译1次，剩下10万次都是纯匹配操作，耗时0.02秒
• 用字符串插值的match?：循环10万次就编译了10万次正则，99%的时间都花在编译上，总耗时9.38秒

而match?的性能优势本来是不生成MatchData对象，但当重复编译的开销远大于匹配本身时，这个优势就完全被掩盖了。

解决办法：提前编译正则一次 #

解决的核心思路就是：把动态拼接的正则提前编译成Regexp对象，之后复用这个对象，不要再重复编译。

修改你的测试代码如下：

str = 'my text with words'
reg_str = '((^|[\s"“])(cherry pie|cherry pies)($|[\s"”\.\,\:\?\!])|(\#(cherrypie|cherrypies)($|\s|\#|\.|\,|\:|\?|\!)))'

# 提前编译正则，只执行一次
compiled_regex = Regexp.new(reg_str, Regexp::IGNORECASE)

puts Benchmark.measure { 100000.times { str.match? compiled_regex } }

运行这段代码，你会发现耗时和直接写死正则的版本几乎一致——因为正则只编译了一次，剩下的都是match?的高效匹配操作，完全发挥了它的性能优势。

额外建议 #

• 如果你的应用中动态正则的内容会变化，可以考虑用哈希缓存不同正则字符串对应的Regexp对象，避免重复编译相同内容的正则。
• 回到你第一个基准测试，动态版本的match?其实还是比match有优势的（0.27秒 vs 0.37秒），只是编译开销缩小了差距；预编译后，这个优势会完全体现出来。

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