自 1.5 版本以来，我们修复了一些 bug 并进行了优化，但最主要的是： Quamina现在支持正则表达式了。这大约是首次提交代码四周年纪念日，也是 v1.0.0 版本发布三周年纪念日。（不过，我最近忙于处理家庭健康问题和其他一些技术方面的爱好。）开源软件，真是一项非常棒的爱好。
我提到过优化吗？ （呜呜）还有回归问题；引入正则表达式对系统的其他部分产生了可衡量的负面影响。但这仍然是值得的权衡。当你发布一款专为模式匹配设计的软件时，它就应该支持正则表达式。关于正则表达式的故事，大约持续了一年，可以从这里开始阅读。
Quamina 的事实
-
代码约 18000 行（不包括生成的代码），其中 12000 行是单元测试。正则表达式功能导致测试运行速度变慢，这很烦人。
-
将 Quamina 添加到您的应用程序中会使可执行文件的大小增加约 100K，这主要是由于 Unicode 表造成的。
-
有一些人工智能辅助代码，但都不太重要。
-
在我的 2023 款 M2 Mac 上，Quamina 实例每秒可以匹配数百万条传入的数据记录，而且对同时匹配的模式数量依赖性不高。当然，前提是正则表达式不太复杂。这是针对每个线程而言的，而 Quamina 的多线程处理能力非常出色。
下一个？
未解决的问题数量不多，但其中一些会很棘手。
我打算暂时忽略那个列表（当然，欢迎提交 PR），先专注于优化。引入 epsilon 转换是为了支持正则表达式，但它们确实会拖慢匹配过程。Quamina 的核心是有限自动机合并逻辑，它包含相当精妙的代码，但遇到 epsilon 转换时通常会束手无策，只能执行最简单的处理方式。有时速度慢得令人恼火。
话虽如此，要进行优化，你需要一个能有效测试被测软件的基准测试。这很棘手，因为 Quamina 速度太快，很难在不让数据输入代码占用过多运行时和内存的情况下，向它提供足够的数据来施加压力。如果有人有构建一个好的基准测试的好主意，我很乐意听听。我正在研究 Go 1.24 中的`b.Loop()` ，有什么理由不选择它吗？
书？
我突然意识到，在攻克 Quamina 的难点时，我做了件很自然的事：上网搜索各种资料和建议。结果却大多令人失望。没错，关于有限自动机的方方面面，网上有很多讲座、博客等等，但它们往往过于理论化，缺乏实际操作，很少谈到如何编写代码来实现它们所描述的功能。
Quamina 日记系列文章现在已经积累了数万字。此外，我之前也写过不少关于 Lark 的文章，Lark 是世界上第一个 XML 解析器，由我编写，基于自动机。所以我认为，或许可以出一本名为《代码战壕中的有限状态自动机》之类的小册子。我敢打赌，这肯定会大卖。我是说，等 Apple TV 把它搬上荧幕之后。
为什么？
说实话，虽然这个项目有不少 star，但我真的不知道谁在生产环境中使用 Quamina。所以，我无法断言这项工作在任何可衡量的方面都让世界变得更美好。
我不太在意，因为我就是控制不住自己。我就是喜欢可执行的抽象概念本身。
原文： https://www.tbray.org/ongoing/When/202x/2026/01/20/Quamina-2.0