从20秒到0.5秒：一个使用Rust语言来优化Python性能的案例(2)

boxed_landingpad 的工作方式很简单.它调用闭包,用 panic :: catch_unwind 捕获 panic,解开结果,并在原始指针中加上成功值.如果发生错误,它会填充 err_out 并返回一个 NULL 指针.在 lsm_view_free 中,只需要从原始指针重新构建.

构建扩展

要实际构建扩展,我们必须在 setuptools 中做一些不太优雅的事情.幸运的是,在这件事上我们没有花太多时间,因为我们已经有一个类似的工具来处理.

这个做法最方便的部分是源代码用 cargo 编译,二进制安装最终的 dylib,消除任何最终用户使用 Rust 工具链的需要.

那些做得好,那些没做好?

我在 Twitter 上被问到：“ Rust 会有什么替代品?”说实话,Rust 很难替代.原因是,除非你想用性能更好的语言重写整个 Python 组件,否则只能使用本机扩展.在这种情况下,对语言的要求是相当苛刻的：它不能有一个侵入式运行时,不能有一个 GC,并且必须支持 C ABI.现在,我认为适合的语言是 C,C++ 和 Rust.

哪方面工作的好：

• 结合 Rust 和 Python 与 CFFI.有一些替代品,链接到 libpython,但构建更复杂.
• 在老一些的 CentOS 版本使用 Docker 来构建可移植的 Linux 容器.虽然这个过程是乏味的,然而不同的 Linux 发兴版和内核之间的稳定性的差异使得 Docker 和 CentOS 成为可接受的构建解决方案.
• Rust 生态系统.我们使用 crates.io 的 serde 反序列化和 base64 库,两个库工作非常好.此外,mmap 支持使用由社区 memmap 提供的另一库.

哪方面工作的不好：

• 迭代和编译时间真的可以更好.我们每次更改字符时都编译模块和头文件.
• setuptools 步骤非常脆弱.我们可能花了更多的时间来使 setuptools 工作.幸运的是,我们以前做过一次,所以这次更容易.

虽然 Rust 对我们的工作帮助很大,毫无疑问,有很多需要改进.特别是,用于导出 C ABI(并使其对 Python 有用)的基础设施应该有很大改进空间.编译时间也不是很长(译者的话,不是很长的意思是可能够我沏杯茶,怀念 go 的编译速度).希望增量编译将有所帮助.

下一步

其实我们还有更多的改进空间.我们可以以更高效的格式启动缓存,比如一组存储在内存中的结构体而不是使用解析 JSON.特别是,如果与文件系统缓存配对,我们几乎可以完全消除加载的成本,因为我们平分了索引,这可以使用 mmap 非常有效.

鉴于这个好的结果,我们很可能会评估 Rust 更多在未来处理一些 CPU 密集型的业务.然而,对于大多数其他操作,程序花更多的时间等待 IO.

小结

虽然这个项目取得了巨大的成功,但是我们只花了很少的时间来实现.它降低了我们的处理时间,它也将帮助我们水平扩展.Rust 一直是这个工作的完美工具,因为它允许我们将昂贵的操作使用本地库完成,而且不必使用 C 或 C ++(这不太适合这种复杂的任务).虽然很容易在 Rust 中编写 source map 解析器,但是使用 C / C++ 来完成的话,代码更多,且没那么有意思.

我们确实喜欢 Python,并且是许多 Python 开源计划的贡献者.虽然 Python 仍然是我们最喜欢的语言,但我们相信在合适的地方使用合适的语言.Rust 被证明是这项工作的最佳工具,我们很高兴看到 Rust 和 Python 将来会带给我们什么.

译者注：不熟悉 source map 的同学请看阮一峰的这篇文章 ?http://www.ruanyifeng.com/blog/2013/01/ javascript_source_map.html

文章出处：高可用架构

（编辑：ASP站长网）