文章介绍了PgDog团队用Rust直接绑定C库的方式替代Protobuf序列化，使SQL查询解析速度提升5倍、反解析速度提升10倍。这一优化显著提高了PostgreSQL代理的性能表现。

用Rust替代Protobuf实现5倍性能提升

核心内容： PgDog团队通过用Rust直接绑定C库的方式，替代原有的Protobuf序列化方案，使SQL查询解析性能提升5倍，反解析性能提升10倍。

技术细节： 1. 性能对比： - 解析查询：从613次/秒提升至3357次/秒（5.45倍） - 反解析AST：从759次/秒提升至7319次/秒（9.64倍）

2. 优化过程：

   • 通过性能分析工具samply发现Protobuf序列化是瓶颈
   • 最初尝试缓存方案，但遇到ORM生成大量独特语句等问题
   • 最终使用bindgen和AI辅助生成6000行Rust代码，实现C结构体与Rust的直接转换

3. 实现方案：

   • 采用递归算法处理AST树结构
   • 保留原有Protobuf定义的结构体，确保兼容性
   • 通过自动化测试验证新旧实现结果完全一致

项目背景： PgDog是一个PostgreSQL扩展代理，原本使用libpg_query的Protobuf绑定进行SQL解析。这次优化显著降低了CPU使用率和延迟，为其作为数据库中间件的性能要求提供了更好支持。

（注：省略了原文中招聘信息、联系方式等非技术内容，保留了核心的技术方案和性能数据）

以下是评论内容的总结：

1. 关于性能提升的质疑

• 有评论认为性能提升并非来自Rust本身，而是架构改变（如去除序列化步骤）所致
  • "他们完全改变了持久化系统...用Lua也能快3倍"（评论1）
  • "直接内存拷贝当然比发送Protobuf快"（评论8）

2. 对标题的争议

• 部分用户认为标题具有误导性，暗示Rust带来性能提升
  • "标题让人误以为是Rust带来5倍提升，实际反而拖慢速度"（评论12）
  • "应该叫'直接内存拷贝比Protobuf更快'"（评论8）
• 也有用户认为标题在博客语境下合理
  • "这是产品博客，不是新闻出版物"（评论11）

3. 技术方案讨论

• 关于跨语言调用的技术选择：
  • "他们用真正的FFI替代了Protobuf类型系统"（评论6）
  • "如果用C语言编写就不需要转换"（评论12）
• 关于内存共享的风险：
  • "进程间内存共享非常不稳定"（评论10）

4. Protobuf替代方案

• 用户提到其他序列化方案：
  • "FlatBuffers已经更快"（评论3）
  • "Cap'n Proto声称无限倍快于Protobuf"（评论4）
• 关于协议选择的实用性讨论：
  • "普通公司真的需要Protobuf吗？JSON不够用？"（评论5）

5. 实现方式的批评

• 有评论指出性能对比不公平：
  • "这是架构设计问题，不是协议问题"（评论14）
  • "我用汇编写Protobuf处理，能说比Rust快1000倍吗"（评论9）

6. 关于Rust的争议

• 部分用户质疑Rust的实际贡献：
  • "其实是C的功劳，但用Rust来蹭热度"（评论13）
  • "应该叫'如何降低使用Rust的性能损失'"（评论12）

关键引用： - "Problem is that it is slow...they wrote their own non-portable but much more optimized Rust-to-C bindings"（评论12） - "using a transport serialization...for IPC. It is obvious why there was an overhead"（评论14）