在软件工程领域，「理论指导实践」几乎是金科玉律 —— 先设计架构，再实现代码，最后优化性能。然而加拿大计算机科学家 Daniel Lemire 的职业轨迹却走了一条截然相反的路：他的方法论核心是先让系统跑起来，在实测中形成对问题的真正理解，然后再归纳出可用于指导后续决策的理论。这种经验主义路线，贯穿了他从地质数据处理到 JSON 解析库开发的全部工程实践。
从地质数据开始的顿悟
Lemire 在多伦多大学攻读博士期间，接触了一批地质学家提交的电磁波探测数据。这批数据由直升机吊挂的气球环向地面发射电磁波后采集回波信号，理论上应呈指数衰减曲线，但实际数据充满了无法直接喂入程序的噪声。导师将清洗任务交给这位年轻的博士生，Lemire 很快发现：设计算法是一回事，验证算法是否有效则是另一回事 —— 程序运行一次要耗费数小时，地质学家们将输出结果扔在桌上，说「等有空了再看」。
这段经历让 Lemire 深刻意识到：慢速计算会制造摩擦，将本可实现的想法阻隔在实践之外。当验证周期从分钟拉长到小时，开发者与协作者都会本能地回避试错。性能不是优化工作的副产品，而是决定研究能否推进的先决条件。他随后加入加拿大国家研究委员会（NRC），在那里他与 MOOC 发明者 Stephen Downes 共事，并逐渐形成了自己的方法论雏形：当没有人知道该怎么做时，先动手做，在做的过程中形成方向感。
第一性原理：「能跑多快？」而非「为什么慢？」
Lemire 方法论中最具辨识度的思维工具，是将问题框架从「为什么它这么慢」翻转为「它理论上能跑多快」。他将这种思路归功于 Elon Musk 的第一性原理推演 —— 不是在现有方案上修修补补，而是从物理约束和资源上限出发，计算出一个不受当前实现束缚的理论目标值。
以 CSV 文件解析为例。业界普遍接受的观点是磁盘 I/O 是瓶颈，代码优化意义不大。Lemire 没有接受这个结论，而是先问：现代消费级设备的磁盘吞吐量是多少？PlayStation 5 的磁盘读取速度超过 5 GB/s，而当时最快的 CSV 解析库在高端 CPU 上只能达到 300 MB/s—— 两者之间存在超过十倍的差距。他说服自己这绝非磁盘的极限，而是软件的瓶颈。随后他与合作者 Geoff Langdale 着手构建基准测试，并最终将 JSON 解析性能从 300 MB/s 提升到 3–4 GB/s，实现了一个数量级的跨越。
这一转向的关键在于：理论上限提供了一个「约束空间」，工程师在此空间内有了明确的优化方向和放手去做的底气。知道当前距离天花板还有十倍改进余地，比「这里可能还有优化空间」的模糊直觉更有行动指导价值。
可操作的工程参数：内存、并行与抽象
Lemire 在访谈中提炼出几项可直接应用于工程的参数建议，这些参数均来自他对真实代码的实测观察。
内存分配策略。现代解析库的主要开销往往不在 CPU 计算本身，而在频繁的堆分配与垃圾回收。高效的实现会预先申请大块内存缓冲区，在缓冲区内部完成所有数据解析，避免为每个字段单独创建对象。实测数据表明，激进避免分配可以将解析吞吐量提升数倍。
分支预测与数据依赖。现代超标量处理器在理想情况下每周期可执行三条指令，但如果代码中存在数据依赖链（即当前指令的结果是下一条指令的输入），流水线的并行度会被打断。同样，条件分支若难以预测，处理器会引入巨大的回滚成本。优化方向是消除不必要的数据依赖和减少条件分支，用无依赖的连续操作填满流水线。实测中，Apple M 系列芯片可以在单核上同时发起 25 次内存请求，远超开发者的直觉预期。
抽象层级与控制权。高层 API 虽然代码美观、表达力强，但往往引入中间层带来的性能损耗。Lemire 将其比作「用吸管喝啤酒」—— 优雅但永远不会在竞速中获胜。对于性能敏感路径，放弃部分抽象换取对硬件行为的直接控制，往往是值得的 trade-off。
SIMD 向量化。在解析这类数据密集型任务中，利用 SIMD 指令在单次操作中处理多个字节是突破性能瓶颈的关键手段之一。Lemire 的团队在实现快速 JSON 解析器时，大量使用了 SSE/AVX 指令集的批处理能力。
交付价值：代码先于论文
Lemire 方法论的另一个核心主张是：研究成果若未触达实际使用者，其价值就停留在学术计数器的虚荣上。NRC 时期的同事 Martin Brooks 曾做过一个著名的比喻：学术界的研究人员做完原型后「把东西扔过墙」，希望墙那边有人接住继续做，但事实往往是墙后空无一人。Lemire 从那次分享中获得的核心洞察是：开源不仅是代码的开放，更是与使用者社区建立持续互动的社会行为。
他的 GitHub 项目往往由数十位贡献者共同维护，其中不乏来自不同国家、说着不同语言的实际用户。这种协作模式的收益是双向的：用户反馈能直接揭示代码中的瓶颈和改进方向，而 Lemire 则需要持续保持对多个主流语言生态的兼容 ——Java、Python、JavaScript、C++—— 以便让代码触达更广泛的受众。这与学术发表「写完即归档」的路径截然不同。
经验主义方法论的实践边界
Lemire 的路线并非在所有场景下都是最优解。对于需求尚未稳定的探索阶段，快速原型验证比极致性能更有价值；对于团队技术栈受限的企业环境，引入 SIMD 级别的手工优化可能引入过高的维护成本。他的方法论更适用于明确存在性能瓶颈、数据规模已知且优化回报可量化的工程场景。
在实践中，一个可操作的启动流程是：首先用基准测试建立当前性能基线；然后计算理论上限（磁盘吞吐量、网络带宽或内存带宽，取其中最小者）；随后将实测值与理论值对比 —— 若差距超过一个数量级，优化工作就具备了优先级的合理性。这一框架将性能优化从「凭感觉优化」转变为「有数据支撑的工程决策」，正是 Lemire 经验主义方法论的精髓所在。
来源：本文核心内容基于 CoRecursive 播客「Frontiers of Performance with Daniel Lemire」访谈整理，Daniel Lemire 为加拿大自然科学研究委员会研究员、TÉLUQ 大学计算机科学教授，以高性能数据处理库闻名于开源社区。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。