1. 個別 regex 層次：妥善處理 submatch extraction、backreference。
2. n 個 regex 層次。

以第一個層次而言，我贊成 Russ Cox 的說法：

[...] it would be reasonable to use Thompson’s NFA simulation for most regular expressions, and only bring out backtracking when it is needed. A particularly clever implementation could combine the two, resorting to backtracking only to accommodate the backreferences.

不過這問題相當複雜，Cox 文章之後引發的討論也相當多。

至於第二個層次，如果這個 regex associative array 資料結構只需 batch insert 及 query，不需 update 及 delete，我想短期之內最快的實現方法，還是用 lex 之類的工具產生一個 compile-time 的 skeleton。

不知道 sendmail、spam filter 之類的系統是如何做的？

若限定只接受 FA 可處理的 perl regex，是可以造出一個 FA 來判斷 input string 是否被 n regex or 起來的 FA accept，complexity = O(strlen(input string))。
若不只是判斷 match，還要在 n 個 regex 裡，找到一個能與該字串吻合的 regex，也許也可以做到，不過還要想想就是。

至於 O(log(n)) 感覺是不大可能，要能達到 log，似乎需要一次能讓 search space 減為 1/k 的方法，目前能想到滿足這條件的通常要有 ordered 或 monotonic function 這樣的特性 (想想 binary search or search tree)。FA 似乎沒有這種特性?

順道一提，我猜如果問題是：在 n 個 regex 裡，找所有能與該字串吻合的 regex，complexity 應該會是 O(n)。
想法和上面差不多，當答案可能有 n 個時，似乎不存在一個比 O(n) 還好的描述法來描述答案。若是有 ordered 特性的話，不管答案有幾個，都可以用二個值：上下界來描述答案 (C++ STL 的 equal_range 就是如此)，但 in general regex 似乎沒有更好的改進描述法的特性?

@jeffhung：你提的方法，就是 Adblock Plus 用的方法，差別只在於 “shortcut” 的取法。

Regular Expression Matching Can Be Simple And Fast
(but is slow in Java, Perl, PHP, Python, Ruby, …)

http://swtch.com/~rsc/regexp/regexp1.html

@單中杰：Perl 的 grep 的確與 Unix 的 grep 不同，但你所提供的文獻卻令我驚訝。

兩個問題需要再檢討：

1. Perl6 是否有改進？
2. Java 的 Pattern.compile() 是否真的有在內部轉換成 FA？

print join(",", grep { 123 % $_ == 0 } 1..123), "\n";
1,3,41,123

所以應該沒有什麼 O(log(n)) 的效率可言。更何況 Perl 根本沒有做到 regex 的基本算法，所以就算是拿單一字串配對單一 regex 都可能花費 exponential time。

要是 Perl 有做到 regex 的基本算法的話，就可以於 runtime 把許多要配對的 regex 組合成一個 regex 再進行配對，以達成優於 O(n) 的效率。