一次查询编译只要5微秒:JIT离数据库标配还有多远

一个正则表达式引擎,只支持字面量和重复两种功能,不到20行代码。解释执行它,比针对这段正则手写的专用代码慢了10到20倍——这个数字不稀奇,任何解释器对上手写代码基本都是这个待遇。

稀奇的是接下来这步:作者把这套逻辑现场编译成ARM64机器码,编译耗时压到了大约5微秒。放进他自己的项目pgrust里,这意味着理论上每一条SQL查询都能单独被编译,而不是像现在的数据库那样,只挑一小撮反复执行的查询做优化。

5微秒是怎么测出来的,能信几分

这个数字来自作者自己的测试。他没有公开硬件型号、样本数量、多次运行的方差。demo本身也很克制:只在macOS ARM64上跑通,正则功能只有字面量和重复,连完整的正则语法都没实现。5微秒是真实存在的一次测量,但不是一个能直接套用到任意数据库、任意查询上的通用值。

技术路径叫copy-and-patch。先为每种操作准备一段"模板"汇编,叫stencil,比如"比较一个字符,不匹配就跳转"。编译具体逻辑时不从头写汇编,是往模板里填空——填进具体字符、具体跳转地址——再把填好的模板逐段拼起来,写进运行时申请的一块可执行内存,当成一个普通函数调用。

demo里那段b(an)*正则,编译出的代码定了几条硬编码的约定:字符串以NUL结尾,省掉长度判断;一个栈专门存回溯位置;x0记录当前扫描位置,x1、x2记录回溯栈的顶和底。匹配失败时,代码去查栈里存过的退路。说白了,是把递归回溯摊平成了一串手工排布的寄存器操作和跳转指令。

把这条路径放进现有的JIT谱系里看,差别更清楚:

主流数据库比如PostgreSQL,已经在用LLVM做JIT,但编译延迟本身不便宜,通常要反复执行很多次的查询才划得来,所以大多数查询还是走解释执行。pgrust想解决的正是这个问题:编译快到可以忽略不计,理论上每条查询都能编译。

5微秒能换来什么,谁该关心

JIT编译真正值钱的地方,从来不是"生成代码快",而是能不能用上运行时才知道的信息——具体的查询计划、具体的数据类型——生成比通用解释器更专的代码。编译延迟压到微秒级,解决的是"能不能覆盖每一条查询"的问题,不解决"每条查询是否值得编译"的问题。

举个例子:一条查询本身只需要几微秒就能跑完,编译哪怕只要5微秒,也可能占了总耗时的一大半,这种查询编译了反而亏。只有查询执行时间明显长于编译开销,或者会被反复调用很多次,编译才划算。这个盈亏平衡点,demo给不出答案,得拿真实负载去测。

下面这张图是示意,柱状的具体高度不是测量数据,只用来说明三者的相对位置:

JIT编译追求的是让通用引擎跑出接近手写专用代码的速度,具体能提升多少,因查询和数据规模不同,原文没有给出可验证的统一倍数,这里也不替它承诺。

对数据库和编程语言基础设施的开发者,这件事值得关注,但不必急着搬。真要评估,先拿自己系统里的真实查询分布测两个数字:查询本身的平均执行时间,以及同一查询被重复执行的次数。如果大多数查询执行时间本来就短、重复次数也低,微秒级JIT省下的编译时间,可能还不够覆盖引入一套JIT系统的复杂度。

对关注AI辅助系统编程的工程师,更该看的是方法论:AI能不能帮着写出正确的、贴合特定调用约定的汇编模板。这次demo证明AI辅助能做到跑通的程度,但跑通不等于经过验证——复制这套代码去x86-64或者接入生产环境之前,调用约定、栈布局、内存安全都得重新过一遍,不能假设AI生成的汇编天然正确。

我的判断:门槛降了,天花板没动

AI在这里干的事,说白了是帮着写汇编。这原本是最需要经验的一步,不熟悉ARM64调用约定和栈布局的人,很难信心十足地手写出demo里那几十行机器码。AI辅助把这道门槛压低了一截,这是这次实验里最实的一条增量。

但门槛降低和收益兑现是两件事。原来只有养得起汇编专家的团队才敢碰的技术,现在一个人的项目也能做出demo级的效果——这是准入门槛的变化,不是性能天花板的变化。

编译器出现,写机器语言的人变少了;高级语言普及,手写汇编的人更少了。每一次门槛下降,都有人喊"这下人人都能干",但真正决定输赢的从来是后面那部分苦活:跨平台支持、内存安全、调试工具链、长期维护。

x86-64和ARM64的调用约定、跳转编码、可执行内存的申请方式都不一样,一套stencil换个平台基本要重写。真要覆盖主流CPU架构,工程量不是翻一倍,是再来一遍。

接下来该看的是:这套copy-and-patch方案能不能啃下x86-64,能不能撑起完整的正则语法乃至真实SQL执行计划,能不能在真实查询负载上测出净收益。这几个坎过不去,5微秒就还是一个人项目里的漂亮数字。

【锐评】汇编门槛真降了,生产账目还没平——5微秒买不来一条完整的JIT流水线。