Nucleo

nucleo 是一个用 Rust 编写的性能极高的模糊匹配器。它的目标是填补与 fzf 和 skim 相同的使用场景。与 fzf 相比，nucleo 具有显著更快的匹配算法。这主要在匹配大量项目上具有低选择性时才有所体现。以下基准测试部分显示了（非科学的）比较。

注意：如果您正在寻找 fuzzy-matcher crate 的替代品，而不是一个完全管理的模糊选择器，则应使用 nucleo-matcher crate。

nucleo 使用与 fzf 完全相同的评分系统。这意味着您应该获得与您在 fzf 中习惯的相同（或更好）的排名质量。然而，nucleo 对 Smith-Waterman 算法的实现更为忠实，该算法通常用于 DNA 序列比对（见 https://www.cs.cmu.edu/~ckingsf/bioinfo-lectures/gaps.pdf），它使用两个单独的矩阵（而不是像 fzf 中的一个）。这意味着 nucleo 更频繁地找到最佳匹配。例如，如果您在 xf foo 中匹配 foo，nucleo 将匹配 x__foo，而 fzf 将匹配 xf_oo（您可以增加单词长度，结果将保持不变）。前者是更直观的匹配，并且根据 nucleo 和 fzf 的排名系统具有更高的分数。

与 skim（以及 fuzzy-matcher 包）相比，nucleo 具有更大的性能优势，通常比前者快约 六倍（见下文基准测试）。此外，nucleo 和 fzf 所使用的奖励系统（在我看来）更为一致/优越。nucleo 还能更好地处理非ASCII文本。（skim 的奖励系统和不区分大小写的功能仅适用于ASCII。）

Nucleo 还能更正确地处理 Unicode 图形符号。 Fzf 和 skim 都在 Unicode 代码点上操作（字符）。这意味着多代码点图形符号可能会产生奇怪的效果（多次匹配、分数异常变化等）。nucleo 将始终使用图形符号的第一个代码点进行匹配（并报告图形符号索引，以便正确突出显示）。

状态

Nucleo 被用于 helix-editor，因此拥有庞大的用户群，并经过了大量的实际测试。核心匹配器实现被认为是完整的，不太可能看到重大变化。《code>nucleo-matcher 包已经完成，准备广泛使用，重大更改应该非常罕见（1.0 版本应该不远了）。

虽然高层 nucleo 包也运行良好（并且也被用于 helix），但未来还将添加更多功能。高层包还需要更好的文档，并且未来可能会看到一些 API 变更。

基准测试

正在进行中，目前更多的是演示而非全面的基准测试套件，特别是与 fzf 的科学比较仍然缺失（因为无法作为库调用，很痛苦）

匹配器微基准测试

比较各种模式与 Linux 内核源代码中所有文件的运行时。在您的系统上重复执行以下操作：BENCHMARK_DIR=<path_to_linux> cargo run -p benches --release（您可以指定空目录，内核会自动克隆）。

与 fzf 的比较

例如，在以下两个屏幕录制中，模式 ///. 被粘贴到 fzf 和 nucleo 中（两者都大约打开了 300 万个项目）。

fzf 过滤文本需要一段时间（大约 1 秒），而 nucleo 几乎没有任何可感知的延迟（屏幕录制中的单帧，所以大约 1/30 秒）。这个比较是在一个非常强大的 CPU（Ryzen 5950x）上进行的，所以在较慢的系统上，差异可能更大。

未来工作

• 将集成到 helix
• 构建一个独立的 CLI 应用程序
  • 达到与 fzf 的功能对等（主要是 --no-sort 和 --tac）
  • 添加列匹配功能
• 暴露 C API，以便高层 API 和匹配算法本身都可以在其他应用程序中使用（如各种 nvim 插件）