最快的子串搜索算法是什么？

Question

好的，所以我听起来不像个白痴，我将更明确地说明问题/要求：

• Needle（模式）和 haystack（要搜索的文本）都是 C 样式的以空值结尾的字符串。没有提供长度信息；如果需要，必须进行计算。
• 函数应返回指向第一个匹配项的指针，如果未找到匹配项，则返回 NULL。
• 不允许出现故障情况。这意味着任何具有非常量（或大常量）存储要求的算法都需要有一个用于分配失败的回退情况（并且回退处理中的性能会导致最坏情况下的性能）。
• 使用 C 语言实现，尽管在没有代码的情况下对算法（或指向此类的链接）进行良好描述也可以。

...以及我所说的“最快”：

• 确定性O(n) 其中n = 干草堆长度。 （但如果将通常为 O(nm) 的算法（例如滚动哈希）与更强大的算法相结合以提供确定性的 O(n) 结果，则可以使用它们的想法。
• 从不执行（可衡量；if (!needle[1]) 等的几个时钟都可以）比天真的蛮力算法更差，尤其是在可能最常见的情况下非常短的针头上。 （无条件的大量预处理开销是不好的，因为试图以牺牲可能的针头为代价来提高病理针头的线性系数也是如此。）
• 与任何其他广泛实施的算法相比，给定任意针和草垛，性能相当或更好（搜索时间不差 50%）。
• 除了这些条件之外，我将对“最快”的定义保持开放式。一个好的答案应该能解释为什么您认为您建议的方法“最快”。

我当前的实现比 glibc 的 Two-Way 实现慢大约 10% 到快 8 倍（取决于输入）。

更新：我目前的最优算法如下：

• 对于长度为 1 的针，请使用 strchr。
• 对于长度为 2-4 的指针，使用机器字一次比较 2-4 个字节，如下所示：在 16 位或 32 位整数中预加载指针并进行移位，然后循环从大海捞针中取出旧字节/循环输入新字节在每次迭代中。 haystack 中的每个字节都只读取一次，并会针对 0（字符串结尾）和 16 位或 32 位比较进行检查。
• 对于长度 >4 的针，使用带有错误移位表（如 Boyer-Moore）的双向算法，该移位表仅适用于窗口的最后一个字节。为了避免初始化 1kb 表的开销，这对于许多中等长度的针来说将是一个净损失，我保留了一个位数组（32 字节）来标记移位表中的哪些条目被初始化。未设置的位对应于从未出现在针中的字节值，因此可以进行全针长度移位。

留在我脑海中的大问题是：

• 有没有办法更好地利用坏班次表？ Boyer-Moore 通过向后（从右到左）扫描来充分利用它，但双向需要从左到右扫描。
• 对于一般情况（没有内存不足或二次性能条件），我发现的唯一两个可行的候选算法是Two-Way 和String Matching on Ordered Alphabets。但是是否存在易于检测的不同算法最佳的情况？当然，空间算法中的许多O(m)（其中m 是针长度）可以用于m<100 左右。如果有一个简单的针测试可证明只需要线性时间，那么也可以使用最坏情况二次算法。

奖励积分：

• 您能否通过假设 needle 和 haystack 都是格式良好的 UTF-8 来提高性能？ （对于不同字节长度的字符，格式良好会在针头和干草堆之间施加一些字符串对齐要求，并在遇到不匹配的头字节时允许自动 2-4 字节移位。但是这些约束是否会给您带来很多/超出什么最大后缀计算、良好的后缀移位等已经为您提供了各种算法？）

注意：我很了解大多数算法，只是不知道它们在实践中的表现如何。这是一个很好的参考，所以人们不会一直给我关于算法的参考作为 cmets/answers：http://www-igm.univ-mlv.fr/~lecroq/string/index.html

Answer 1

我不知道这是否绝对是最好的，但我对 Boyer-Moore 有很好的体验。

Answer 2

建立一个包含可能的针和干草堆的测试库。分析几种搜索算法的测试，包括蛮力。选择对您的数据表现最好的那个。

Boyer-Moore 使用坏字符表和好的后缀表。

Boyer-Moore-Horspool 使用了错误的字符表。

Knuth-Morris-Pratt 使用部分匹配表。

Rabin-Karp 使用运行哈希。

它们都在不同程度上用开销来减少比较，因此现实世界的性能将取决于针头和干草堆的平均长度。初始开销越多，输入越长越好。用很短的针，蛮力可能会赢。

编辑：

另一种算法可能最适合查找碱基对、英语短语或单个单词。如果所有输入都存在一种最佳算法，它就会被公开。

想想下面这张小桌子。每个问号可能有不同的最佳搜索算法。

                 short needle     long needle
short haystack         ?               ?
long haystack          ?               ?

这实际上应该是一个图表，每个轴上的输入范围从短到长。如果您在这样的图上绘制每个算法，每个算法都会有不同的签名。一些算法在模式中存在大量重复，这可能会影响搜索基因等用途。影响整体性能的其他一些因素是多次搜索相同的模式并同时搜索不同的模式。

如果我需要一个样本集，我想我会抓取像谷歌或维基百科这样的网站，然后从所有结果页面中删除 html。对于搜索站点，输入一个单词，然后使用建议的搜索短语之一。如果适用，请选择几种不同的语言。使用网页，所有的文本都是短到中等的，所以合并足够多的页面以获得更长的文本。您还可以找到公共领域的书籍、法律记录和其他大量文本。或者只是通过从字典中挑选单词来生成随机内容。但分析的重点是针对您要搜索的内容类型进行测试，因此请尽可能使用真实世界的样本。

我含糊其辞。对于针，我认为短是 8 个字符以下，中是 64 个字符以下，长是 1k 以下。对于大海捞针，我认为短小于 2^10，中小于 2^20，最长不超过 2^30 个字符。

Answer 3

http://www-igm.univ-mlv.fr/~lecroq/string/index.html 你指向的链接是 一些最知名和研究的优秀来源和摘要 字符串匹配算法。

大多数搜索问题的解决方案包括 在预处理开销、时间和 空间要求。没有单 算法在所有情况下都是最优的或实用的。

如果你的目标是为字符串搜索设计一个特定的算法，那么忽略 剩下的我要说的，如果你想开发一个通用的字符串搜索服务 例程然后尝试以下操作：

花一些时间回顾一下具体的优势和劣势 您已经引用的算法。进行 审查的目的是找到一组 涵盖字符串搜索范围和范围的算法 感兴趣。然后，构建一个基于分类器的前端搜索选择器 函数以针对给定输入的最佳算法。这样你就可以 采用最有效的算法来完成这项工作。这尤其 当算法对某些搜索非常好但降级很差时有效。为了 例如，对于长度为 1 的针，蛮力可能是最好的，但是 随着针长度的增加，sustik-moore algoritim 可能会变得更有效（相对于小字母），然后对于更长的针和更大的字母，KMP 或 Boyer-Moore 算法可能会更好。这些只是说明可能策略的示例。

多重算法方法并不是一个新想法。我相信它已被少数人使用 商业排序/搜索包（例如大型机上常用的 SYNCSORT 实现 几种排序算法，并使用启发式方法为给定输入选择“最佳”算法）

每种搜索算法都有几种变体 可以对其性能产生重大影响，因为， 例如，这个paper 说明了。

对您的服务进行基准测试，以对需要额外搜索策略的区域进行分类或更有效地进行分类 调整您的选择器功能。这种方法并不快速或容易，但如果 做得好可以产生非常好的结果。

Answer 4

您可能还希望对多种类型的字符串进行不同的基准测试，因为这可能会对性能产生很大影响。算法将根据搜索自然语言（即使在这里仍然可能由于不同的形态学而存在细粒度的区别）、DNA 字符串或随机字符串等来执行不同的操作。

字母大小将在许多算法中发挥作用，针的大小也是如此。例如，由于字母大小不同，Horspool 在英文文本上做得很好，但在 DNA 上做得不好，这让坏字符规则很难受。引入 good-suffix 可以大大缓解这种情况。

Answer 5

一个非常好的问题。只需添加一些微小的部分...

1. 有人在谈论 DNA 序列匹配。但是对于 DNA 序列，我们通常做的是为大海捞针构建一个数据结构（例如后缀数组、后缀树或 FM-index）并匹配许多针。这是一个不同的问题。

2. 如果有人想对各种算法进行基准测试，那就太好了。压缩和后缀数组的构建有非常好的基准，但我还没有看到字符串匹配的基准。潜在的干草堆候选人可能来自SACA benchmark。

3. 几天前我正在测试 the page you recommended 的 Boyer-Moore 实现（编辑：我需要一个像 memmem() 这样的函数调用，但它不是标准函数，所以我决定实现它） .我的基准测试程序使用随机 haystack。似乎该页面中的 Boyer-Moore 实现比 glibc 的 memmem() 和 Mac 的 strnstr() 快几倍。如果您有兴趣，实现是here，基准代码是here。这绝对不是一个现实的基准，但它是一个开始。

Answer 6

使用标准库strstr:

char *foundit = strstr(haystack, needle);

速度非常快，只花了我大约 5 秒的时间打字。

Answer 7

这里是Python's search implementation，在整个核心中使用。 cmets 表明它使用 压缩的 boyer-moore delta 1 表。

我自己对字符串搜索进行了一些相当广泛的实验，但它是针对多个搜索字符串的。 Horspool 和 Bitap 的汇编实现通常可以对抗 Aho-Corasick 这样的算法，因为它们的模式计数较低。

Answer 8

更快的“搜索单个匹配字符”（ala strchr）算法。

重要提示：

• 这些函数使用“（前导|尾随）零的数量/计数”gcc 编译器内在-__builtin_ctz。这些函数可能只在具有执行此操作的指令的机器（即 x86、ppc、arm）上才能快速运行。

• 这些函数假定目标体系结构可以执行 32 位和 64 位未对齐加载。如果您的目标架构不支持这一点，您将需要添加一些启动逻辑来正确对齐读取。

• 这些函数与处理器无关。如果目标 CPU 有向量指令，你可能会做得更好。例如，下面的 strlen 函数使用 SSE3，可以简单地修改为 XOR 扫描的字节以查找除 0 之外的字节。在运行 Mac OS X 10.6 (x86_64) 的 2.66GHz Core 2 笔记本电脑上执行的基准测试：

  • strchr 为 843.433 MB/s
  • findFirstByte64 为 2656.742 MB/s
  • strlen 为 13094.479 MB/s

... 32 位版本：

#ifdef __BIG_ENDIAN__
#define findFirstZeroByte32(x) ({ uint32_t _x = (x); _x = ~(((_x & 0x7F7F7F7Fu) + 0x7F7F7F7Fu) | _x | 0x7F7F7F7Fu); (_x == 0u)   ? 0 : (__builtin_clz(_x) >> 3) + 1; })
#else
#define findFirstZeroByte32(x) ({ uint32_t _x = (x); _x = ~(((_x & 0x7F7F7F7Fu) + 0x7F7F7F7Fu) | _x | 0x7F7F7F7Fu);                    (__builtin_ctz(_x) + 1) >> 3; })
#endif

unsigned char *findFirstByte32(unsigned char *ptr, unsigned char byte) {
  uint32_t *ptr32 = (uint32_t *)ptr, firstByte32 = 0u, byteMask32 = (byte) | (byte << 8);
  byteMask32 |= byteMask32 << 16;
  while((firstByte32 = findFirstZeroByte32((*ptr32) ^ byteMask32)) == 0) { ptr32++; }
  return(ptr + ((((unsigned char *)ptr32) - ptr) + firstByte32 - 1));
}

...和 ​​64 位版本：

#ifdef __BIG_ENDIAN__
#define findFirstZeroByte64(x) ({ uint64_t _x = (x); _x = ~(((_x & 0x7F7F7F7F7f7f7f7full) + 0x7F7F7F7F7f7f7f7full) | _x | 0x7F7F7F7F7f7f7f7full); (_x == 0ull) ? 0 : (__builtin_clzll(_x) >> 3) + 1; })
#else
#define findFirstZeroByte64(x) ({ uint64_t _x = (x); _x = ~(((_x & 0x7F7F7F7F7f7f7f7full) + 0x7F7F7F7F7f7f7f7full) | _x | 0x7F7F7F7F7f7f7f7full);                    (__builtin_ctzll(_x) + 1) >> 3; })
#endif

unsigned char *findFirstByte64(unsigned char *ptr, unsigned char byte) {
  uint64_t *ptr64 = (uint64_t *)ptr, firstByte64 = 0u, byteMask64 = (byte) | (byte << 8);
  byteMask64 |= byteMask64 << 16;
  byteMask64 |= byteMask64 << 32;
  while((firstByte64 = findFirstZeroByte64((*ptr64) ^ byteMask64)) == 0) { ptr64++; }
  return(ptr + ((((unsigned char *)ptr64) - ptr) + firstByte64 - 1));
}

Edit 2011/06/04 OP 在 cmets 中指出该解决方案存在“无法克服的错误”：

它可以读取过去寻找的字节或空终止符，这可以访问未映射的页面或没有读取权限的页面。除非它们对齐，否则您根本不能在字符串函数中使用大量读取。

这在技术上是正确的，但几乎适用于任何对大于单个字节的块进行操作的算法，包括 cmets 中 OP 建议的 the method：

典型的strchr 实现并不幼稚，但比您提供的要高效得多。使用最广泛的算法见文末：http://graphics.stanford.edu/~seander/bithacks.html#ZeroInWord

它本身也与 alignment 本身无关。诚然，这可能会导致在使用的大多数常见架构上讨论的行为，但这更多与微架构实现细节有关 - 如果未对齐的读取跨越 4K 边界（再次，典型），那么该读取将导致程序如果下一个 4K 页面边界未映射，则终止错误。

但这不是答案中给出的算法中的“错误”——这种行为是因为像 strchr 和 strlen 这样的函数不接受 length 参数来限制搜索的大小。搜索char bytes[1] = {0x55};，出于我们讨论的目的，它恰好位于 4K VM 页面边界的最末端，下一页未映射，strchr(bytes, 0xAA)（其中strchr 是一个字节-at- a-time implementation) 将以完全相同的方式崩溃。 strchr 相关表亲 strlen 同上。

如果没有length 参数，就无法判断何时应该退出高速算法并返回到逐字节算法。一个更有可能的“错误”是读取“超过分配的大小”，根据各种 C 语言标准，这在技术上会导致 undefined behavior，并且会被 valgrind 之类的东西标记为错误。

总而言之，任何对大于字节块的操作都会更快，因为这回答了代码和 OP 指出的代码，但必须具有字节准确的读取语义，如果存在没有length 参数来控制“最后一次读取”的极端情况。

此答案中的代码是一个内核，如果目标 CPU 具有类似 ctz 的快速指令，则该内核能够快速找到自然 CPU 字大小块中的第一个字节。添加诸如确保它仅在正确对齐的自然边界或某种形式的length 边界上运行的东西是微不足道的，这将允许您切换出高速内核并进入较慢的逐字节检查.

OP 还在 cmets 中声明：

至于你的 ctz 优化，它只对 O(1) 尾操作有影响。它可以提高小字符串的性能（例如strchr("abc", 'a');，但肯定不能用于任何主要大小的字符串。

这句话是否正确在很大程度上取决于所讨论的微架构。使用规范的 4 阶段 RISC 流水线模型，几乎可以肯定是正确的。但是对于当代的乱序超级标量 CPU 来说，这是否是真的很难说，因为它的核心速度完全可以使内存流速度相形见绌。在这种情况下，“可以退役的指令数”相对于“可以流式传输的字节数”存在很大差距不仅是合理的，而且很普遍，因此您拥有“对于可以流式传输的每个字节，可以退出的指令数”。如果它足够大，ctz + shift 指令可以“免费”完成。

Answer 9

我知道这是一个老问题，但大多数糟糕的班次表都是单字符的。如果它对您的数据集有意义（例如，特别是如果它是书面文字），并且如果您有可用空间，则可以通过使用由 n-gram 而不是单个字符组成的坏移位表来获得显着的加速。

Answer 10

看到我们的技术报告在本次讨论中被引用，我感到很惊讶；我是上面名为 Sustik-Moore 的算法的作者之一。 （我们的论文中没有使用该术语。）

我想在此强调，对我而言，该算法最有趣的特点是证明每个字母最多检查一次非常简单。对于较早的 Boyer-Moore 版本，他们证明每个字母最多检查 3 次，之后最多检查 2 次，并且这些证明涉及更多（参见论文中的引用）。因此，我也看到了展示/研究这个变体的教学价值。

在本文中，我们还描述了在放宽理论保证的同时针对效率的进一步变化。这是一篇简短的论文，我认为这些材料对于普通高中毕业生来说应该是可以理解的。

我们的主要目标是让其他可以进一步改进它的人注意这个版本。字符串搜索有如此多的变化，仅凭我们一个人不可能想到这个想法可以带来的所有好处。 （固定文本和改变模式、固定模式不同文本、预处理可能/不可能、并行执行、在大文本中查找匹配子集、允许错误、接近匹配等等等）

Answer 11

只要搜索“fastest strstr”，如果你看到感兴趣的东西就问我。

在我看来，您对自己施加了太多限制（是的，我们都希望在最大搜索器处实现亚线性），但是需要真正的程序员介入，直到那时我认为散列方法只是一个漂亮的-边缘解决方案（BNDM 很好地加强了较短的 2..16 模式）。

只是一个简单的例子：

将 Pattern(32bytes) 搜索到 String(206908949bytes) 作为一行... 跳过性能（越大越好）：3041%，6801754 次跳过/迭代 Railgun_Quadruplet_7Hasherezade_hits/Railgun_Quadruplet_7Hasherezade_clocks：0/58 Railgun_Quadruplet_7Hasherezade 性能：3483KB/clock

将 Pattern(32bytes) 搜索到 String(206908949bytes) 作为一行... 跳过性能（越大越好）：1554%，13307181 次跳过/迭代 Boyer_Moore_Flensburg_hits/Boyer_Moore_Flensburg_clocks：0/83 Boyer_Moore_Flensburg 性能：2434KB/clock

将 Pattern(32bytes) 搜索到 String(206908949bytes) 作为一行... 跳过性能（越大越好）：129%，160239051 次跳过/迭代 Two-Way_hits/Two-Way_clocks：0/816 双向性能：247KB/时钟

桑梅斯，
问候

Answer 12

您在问题中提到的双向算法（顺便说一句，这令人难以置信！）最近已得到改进，可以一次有效地处理多字节单词：Optimal Packed String Matching。

我还没有阅读整篇论文，但似乎它们依赖于几个新的、特殊的 CPU 指令（包括在例如 SSE 4.2 中）它们的时间复杂度声明为 O(1)，但如果它们不是他们可以在 O(log log w) 时间内对 w 位单词进行模拟，这听起来还不错。

Answer 13

例如，您可以实现 4 种不同的算法。每 M 分钟（根据经验确定）在当前真实数据上运行所有 4 分钟。累积 N 次运行的统计信息（也待定）。然后在接下来的 M 分钟内只使用获胜者。

记录获胜的统计数据，以便您可以用新算法替换永远不会获胜的算法。将优化工作集中在最成功的例程上。对硬件、数据库或数据源进行任何更改后，请特别注意统计信息。如果可能，请将该信息包含在统计日志中，这样您就不必从日志日期/时间戳中找出它。

Answer 14

发表于 2011 年，我相信它很可能是 Dany Breslauer、Roberto Grossi 和 Filippo Mignosi 的 "Simple Real-Time Constant-Space String Matching" 算法。

更新：

2014 年，作者发布了这项改进：Towards optimal packed string matching。

Answer 15

我最近发现了一个很好的工具来衡量各种可用算法的性能： http://www.dmi.unict.it/~faro/smart/index.php

您可能会发现它很有用。 另外，如果我必须快速调用子字符串搜索算法，我会选择 Knuth-Morris-Pratt。

Answer 16

最快的子字符串搜索算法将取决于上下文：

1. 字母大小（例如 DNA 与英文）
2. 针长

2010 年的论文 "The Exact String Matching Problem: a Comprehensive Experimental Evaluation" 提供了包含 51 种算法（具有不同的字母大小和针长）的运行时表，因此您可以根据您的上下文选择最佳算法。

所有这些算法都有 C 实现，还有一个测试套件，在这里：

http://www.dmi.unict.it/~faro/smart/algorithms.php

Answer 17

目前最快的是 EPSM，由 S. Faro 和 O. M. Kulekci 开发。 见https://smart-tool.github.io/smart/

针对 SIMD SSE4.2（x86_64 和 aarch64）优化的“精确打包字符串匹配”。它在所有尺寸上都表现稳定且最佳。

我链接到的网站比较了 199 种快速字符串搜索算法，而常用的（BM、KMP、BMH）非常慢。在这些平台上，EPSM 优于此处提到的所有其他产品。这也是最新的。

2020 年更新：EPSM 最近针对 AVX 进行了优化，并且仍然是最快的。