如何使用Rust提高Ruby性能

原文：Improving Ruby Performance with Rust
作者：Daniel P. Clark
翻译：无阻我飞扬

摘要：Ruby是一种简单快捷面向对象的脚本语言，而Rust是一种系统编程语言，它有着惊人的运行速度，能够防止段错误，并保证线程安全。本文作者以项目为例，结合大量的编程代码描述了如何借助Rust语言提高Ruby的性能，以下是译文。

几年前，在我的Rails（提供一个纯Ruby的开发环境）应用程序里发现了一些被调用数千次的方法，占了网站页面加载时间的30%以上。这些方法都完全地专注于文件路径名。

除此之外，我还看过一篇博客写“拯救Ruby的Rust”，这表明可以用Rust编写执行慢的Ruby代码,让Ruby变得更快。Rust还提供了一种安全、快速、高效的编写代码的方法。在用Rust语言重写了我的Rails站点上一些效率较低的方法之后，网站页面加载速度比以前快了33%以上。

如果想了解通过FFI集成Rust,那么建议看看上文中提到的那篇博客（“拯救Ruby的Rust”）。当前这篇文章的重点是分享我在过去两年整合Ruby和Rust所得到的经验教训。当方法被调用数千次，它的性能稍有改进都会对项目有很大的影响。

入门

这篇文章的相关代码可以在GitHub上看到，如果打算开始了解Rust和Ruby项目，可以创建一个ffi_example 项目，并把下面的代码添加到Cargo.toml文件：

[lib]
name = "ffi_example"
crate-type = ["dylib"]

[dependencies]
array_tool = "*"
libc = "0.2.33"

添加如下代码到ffi_example.gemspec文件：

spec.add_dependency "bundler", "~> 1.12"
  spec.add_dependency "rake", "~> 12.0"
  spec.add_dependency "ffi", "~> 1.9"
  spec.add_development_dependency "minitest", "~> 5.10"
  spec.add_development_dependency "minitest-reporters", "~> 1.1"
  spec.add_development_dependency "benchmark-ips", "~> 2.7.2"

由于构建的库需要在客户端系统上使用FFI，所以最好将FFI，Rake和Bundler作为常规依赖项包含在内。

用于这篇文章的例子，可以从FasterPath的repo历史记录中获取basename方法代码，与File.basename进行比较。

请记住，Ruby用C语言实现了这个功能，所以这并不是你通常会用Rust重写的那种方法。
大多数FasterPath都会为Pathname类重写Ruby代码，这就是可以显著提高性能的地方。
我们正在使用File.basename作为纯粹的比较基准。

为了简单起见，将所有的Rust代码放入到src/lib.rs。这是一个用Rust编写的basename代码副本（可以复制和粘贴它;在这里不再介绍它是如何工作的）：

mod rust {
  extern crate array_tool;
  use self::array_tool::string::Squeeze;
  use std::path::MAIN_SEPARATOR;

  static SEP: u8 = MAIN_SEPARATOR as u8;

  pub fn extract_last_path_segment(path: &str) -> &str {
    // Works with bytes directly because MAIN_SEPARATOR is always in the ASCII 7-bit range so we can
    // avoid the overhead of full UTF-8 processing.
    // See src/benches/path_parsing.rs for benchmarks of different approaches.
    let ptr = path.as_ptr();
    let mut i = path.len() as isize - 1;
    while i >= 0 {
      let c = unsafe { *ptr.offset(i) };
      if c != SEP { break; };
      i -= 1;
    }
    let end = (i + 1) as usize;
    while i >= 0 {
      let c = unsafe { *ptr.offset(i) };
      if c == SEP {
        return &path[(i + 1) as usize..end];
      };
      i -= 1;
    }
    &path[..end]
  }

  pub fn basename(pth: &str, ext: &str) -> String {
    // Known edge case
    if &pth.squeeze("/")[..] == "/" { return "/".to_string(); }

    let mut name = extract_last_path_segment(pth);

    if ext == ".*" {
      if let Some(dot_i) = name.rfind('.') {
        name = &name[0..dot_i];
      }
    } else if name.ends_with(ext) {
      name = &name[..name.len() - ext.len()];
    };
    name.to_string()
  }
}

这个案例是为了模仿File.basename返回结果的方式而写的。这里唯一需要注意的是在basename方法开始的地方的边界情况。这有效地使方法在迭代给定输入的时间加倍，并且应该重构到现有的系统中去。

感谢Gleb Mazovetskiy，extract_last_path_segment是一个有效的贡献。这个方法在其它方法中使用，并在边界情况已知之前就实现了。在本文的后面，将讨论有和没有边界情况下的基准性能的细节。

Rust FFI方法

用于处理字符串显示的打包类的Rust FFI代码如下：

extern crate libc;
use libc::c_char;
use std::ffi::{CStr,CString};


#[no_mangle]
pub extern "C" fn example(c_pth: *const c_char) -> *const c_char {
  let pth = unsafe {
    assert!(!c_pth.is_null());
    CStr::from_ptr(c_pth).to_str().unwrap()
  };

  let output: String = // YOUR CODE HERE

  CString::new(output).unwrap().into_raw()
}

Ruby会通过FFI给出一个原始C类，并将其转换成可以在Rust中使用的字符串，然后再转换回来给到Ruby。

这里需要注意的重要的一点是assert!。这个assert!方法在本文的项目当中并不消耗任何时间，但如果它的求值为false，Rust就会崩溃，带来FFI段错误。所以这个assert!方法有了保证nil不提供输入是很好的。但Ruby是nil友好的，你并不希望段错误发生，所以在这里使用assert!方法是不明智的。

现在nil在Rust中添加检查并不困难。为我们的代码使用同样的打包行为，我将提供basename的nil检查版本。

#[no_mangle]
pub extern "C" fn basename_with_nil(c_pth: *const c_char, c_ext: *const c_char) -> *const c_char {
  if c_pth.is_null() || c_ext.is_null() {
    return c_pth;
  }
  let pth = unsafe { CStr::from_ptr(c_pth) }.to_str().unwrap();
  let ext = unsafe { CStr::from_ptr(c_ext) }.to_str().unwrap();

  let output = rust::basename(pth, ext);

  CString::new(output).unwrap().into_raw()
}

当执行这段代码的时候，如果Ruby给出一个nil，不做任何操作将其返回，系统就会理解这是nil。结果证明这样编写是有效的。

所以在这种情况下，Rust方法可以返回一个String类型或者nil给到Ruby。Ruby甚至不会注意到这完全违背了Rust的类型强制设计; 因为在Rust语言中，只处理一种类型，就是从libc::c_char到c_char。

注意，用一种几乎不耗费时间的方法，做一个nil guard稍微安全一点；然而，这使得我们的方法增加了4%的运行时间（这个时间在没有边界情况下变得慢下来）。如果用Ruby而不是Rust实现nil guard，又会增加4%的运行时间，总计慢下来8个百分点。

请记住，我们在这里吹毛求疵的东西已经极快。平均结果在+/-3%之间。

如果用Ruby提供的File.basename实现相同的类型安全：

def self.basename(pth, ext = '')
  pth = pth.to_path if pth.respond_to? :to_path
  raise TypeError unless pth.is_a?(String) && ext.is_a?(String)
  // Call original Rust FFI implementation without nil guards here
end

会比原来用Rust的实现慢17%左右。

我们甚至还没有将性能与Ruby的C语言实现进行比较。为了使代码完全兼容，这使得我们每种Type Safety Guard类型都要去实现。

释放内存

更糟糕的是，即使在学习进程的这一点上，我们也不知道垃圾回收被调用时内存中发生了什么。这需要对在线文档和博客进行更多的研究，以帮助了解这里面发生了什么。

根据我的经验，我会告诉你，通过挖掘可用的资源，现在并没有完全弄清楚垃圾回收被调用时内存中究竟发生了什么，但是我会给出输入的信息。

据称，当使用FFI时，如果没有实现自己释放内存的方法，那么FFI会尝试调用C的free方法。在与一些Rust社团的讨论中，真的不希望free被Rust代码以这样的方式调用，这通常是未定义的行为或未知发生的事情，或者可能已经发生。因此从几个方面建议你用Rust实现一个方法，它将负责收回原先由Rust所给出的内存所有权，并由Rust去释放它。需要告诉Ruby在代码执行完成时调用这个方法。

在FFI中，很容易链接到自己的“free”方法并手动调用它。或者可以让Ruby通过AutoPointer或ManagedStruct自动执行垃圾收集器。FFI Wiki或Rust Omnibus提供了很好的例子。

如果正在优化的代码方法被频繁的调用，那么实现这些代码的代价就是值得的。但是，如果正在优化的代码速度已经很快，那么这个性能优化的代价就相当高昂，在内存能够正确地提供服务的情况下，我的方法会多花费大约40％的时间。

这其中的原因很大程度上是因为FFI有一部分是用Ruby编写的，大部分是用C语言编写的，用Ruby-land处理逻辑的时间越多，那么从纯C语言或Rust语言的性能得到的益处就越少。

在这之后，当所有这些琐碎的事情加起来，花费的时间比节省的时间还要多的时候，我感到沮丧。那时候，我决定应该避免用Ruby 编写FFI，并尝试去寻求一个纯粹的Rust解决方案。

有两个这样的解决方案：一个叫ruru，另一个叫Helix。在这两者之间，出于以下原因，我最终选择了ruru。

• ruru是用Rust的风格写的， Helix的设计就像用Rust自身写Ruby一样。
• ruru非常接近1.0版本，看起来很稳定，而 Helix正处于周期性的快速发展之中，还有很多大的功能尚未开发出来。

切换到ruru之后，我收回了在实现safe guard 类型中失去的所有的时间。这有点跑题了，但如果没有为前面的例子提供Ruby代码，那么将是我的失职。

Ruby FFI用法

为了进行基准测试，在Ruby里添加一些方法。首先执行lib/ffi_example.rb。

require "ffi_example/version"
require "ffi"

module FfiExample
  # the example function from earlier but with two parameters
  def self.basename_with_pure_input(pth, ext = '')
    Rust.basename_with_pure_input(pth, ext)
  end

  def self.basename_nil_guard(pth, ext = '')
    return nil if pth.nil? || ext.nil?
    Rust.basename_with_pure_input(pth, ext)
  end

  def self.basename_with_nil(pth, ext = '')
    Rust.basename_with_nil(pth, ext)
  end

  def self.file_basename(pth, ext = '')
    pth = pth.to_path if pth.respond_to? :to_path
    raise TypeError unless pth.is_a?(String) && ext.is_a?(String)
    Rust.basename_with_pure_input(pth, ext)
  end

  module Rust
    extend FFI::Library
    ffi_lib begin
      prefix = Gem.win_platform? ? "" : "lib"
      "#{File.expand_path("../target/release/", __dir__)}/#{prefix}ffi_example.#{FFI::Platform::LIBSUFFIX}"
    end

    attach_function :basename_with_pure_input, [ :string, :string ], :string
    attach_function :basename_with_nil, [ :string, :string ], :string
  end
  private_constant :Rust
end

Ruby在标准库中有Fiddle，通过外部函数接口直接调用外部C函数。但是，它基本上没有入门文档，缺少很多功能。这很可能是为什么FFI早就写出来了，但只有少量的文档，它仍然缺乏帮助初学者的条件，让他们可以对发生的事情有充分的了解。

这个ffi提供了一些帮助，使得我们能够编写可以跨多个操作系统运行的代码。上面的ffi_lib方法需要指向Rust建立的动态库。所以当运行cargo build –release的时候，它将在target/release中创建库，并且这种扩展取决于操作系统。上述的begin/ end 代码块适用于Windows，Mac和Linux等操作系统。

ruru入门

Ruru现在相当直接地加入到我们的项目中。首先将其添加到Cargo.toml文件。

[dependencies]
ruru = "0.9.3"
array_tool = "*"
libc = "0.2.33"

然后在外部crate库中使用ruru ,并加入到src/lib.rs文件。

#[macro_use]
extern crate ruru;
use ruru::{RString,Class,Object};

Ruru有一些不错的宏，这些宏有助于我们的方法与特定的类一起工作。首先，定义一个想要创建的类，然后在宏中定义方法，将它们与Ruby类关联起来。

class!(RuruExample);

methods!(
  RuruExample,
  _itself,
  fn pub_basename(pth: RString, ext: RString) -> RString {
    RString::new(
      &rust::basename( pth.ok().unwrap_or(RString::new("")).to_str(), ext.ok().unwrap_or(RString::new("")).to_str() )[..]
    )
  }
);

在methods!宏中，首先选择要使用的类。下一个环节是将在methods!宏块内使用的变量来引用Ruby版本的 self。由于在这个项目里根本就不使用它，在它前面加下划线_itself。

Ruby有用C语言实现的自己的类系统，每个类都有一个用VALUE设置的类标识。Ruru将这些类中的某些类戏称为Rust类，所以对于Ruby的String类，我们使用RString类。

当用methods!宏编写方法时，知道宏的作用域内的方法不能相互调用是非常重要的。因此，要重复使用的任何方法都必须在宏之外编写，并在那里调用它们。另外，当创建动态库时，可能很容易出现命名冲突，所以将额外的字符添加到方法名中是极好的，这样就不会混淆了。接下来会演示…

为了使方法可以从Ruby中调用，必须首先让Ruby调用Rust代码来获取实例化的对象。

#[allow(non_snake_case)]
#[no_mangle]
pub extern "C" fn Init_ruru_example(){
  Class::new("RuruExample", None).define(|itself| {
    itself.def_self("basename", pub_basename);
  });
}

前面的Init_目的是遵循Ruby的惯例，允许直接从库文件中导入一个Ruby C语言风格的编译库。

因此，需要重命名Cargo.toml文件中的库以避免与ruby中名为ffi_example的名称发生冲突，并将target/release路径添加到加载路径，然后应该可以直接请求require "ruru_example"来请求它（如果命名了ruru_example库）。再加载ruru Rust代码就好像它是用Ruby写的。

有关将C语言代码与Ruby相连的更深入的了解，请阅读用于编写C语言扩展的文档。

加载代码的另一种方法是直接使用Fiddle来调用它。在这个例子中，仍然使用FFI的动态库辅助方法。

require 'fiddle'

library = Fiddle.dlopen(
  begin
    prefix = Gem.win_platform? ? "" : "lib"
    "#{File.expand_path("../target/release/", __dir__)}/#{prefix}ffi_example.#{FFI::Platform::LIBSUFFIX}"
  end
)

Fiddle::Function.
  new(library['Init_ruru_example'], [], Fiddle::TYPE_VOIDP).
  call

现在将代码加载到Ruby中，一切都按预期运行。

基准测试

在之前包含的gemspec中，包含了benchmark-ips。为了对方法进行基准测试，首先放入一个Rakefile使得命令行执行变得更简单。

# Rakefile
require "bundler/gem_tasks"
require "rake/testtask"

Rake::TestTask.new(:test) do |t|
  t.libs << "test"
  t.libs << "lib"
  t.test_files = FileList["test/**/*_test.rb"]
end

Rake::TestTask.new(:bench) do |t|
  t.libs = %w[lib test]
  t.pattern = 'test/**/*_benchmark.rb'
end

task :default => :test

现在在test/benches/basename_benchmark.rb创建基准测试。

require 'test_helper'
require 'benchmark/ips'

BPATH = '/home/gumby/work/ruby.rb'

Benchmark.ips do |x|
  x.report('Ruby\'s C impl') do
    File.basename(BPATH)
    File.basename(BPATH, '.rb')
  end

  x.report('with pure input') do
    FfiExample.basename_with_pure_input(BPATH)
    FfiExample.basename_with_pure_input(BPATH, '.rb')
  end

  x.report('ruby nil guard') do
    FfiExample.basename_nil_guard(BPATH)
    FfiExample.basename_nil_guard(BPATH, '.rb')
  end

  x.report('rust nil guard') do
    FfiExample.basename_with_nil(BPATH)
    FfiExample.basename_with_nil(BPATH, '.rb')
  end

  x.report('with type safety') do
    FfiExample.file_basename(BPATH)
    FfiExample.file_basename(BPATH, '.rb')
  end

  x.report('through ruru') do
    RuruExample.basename(BPATH, '')
    RuruExample.basename(BPATH, '.rb')
  end

  x.compare!
end

在运行上述基准测试之前，先从basename方法中评估边界情况。边界情况仅仅是为了通过Ruby Spec Suite。按照文件路径中可接受的标准，不需要将多个斜杠压缩到一个（从///到/），操作系统会很好地识别路径。

现在运行基准测试rake bench产生以下输出结果（确保cargo build --release在运行基准测试之前运行）：

注：Ruby 2.4.2和Rust 1.23.0

Warming up --------------------------------------
       Ruby's C impl    41.849k i/100ms
     with pure input    31.766k i/100ms
      ruby nil guard    29.974k i/100ms
      rust nil guard    31.812k i/100ms
    with type safety    27.103k i/100ms
        through ruru    41.124k i/100ms
Calculating -------------------------------------
       Ruby's C impl    683.942k (± 1.5%) i/s -      3.432M in   5.018615s
     with pure input    480.551k (± 1.6%) i/s -      2.414M in   5.025184s
      ruby nil guard    443.185k (± 2.6%) i/s -      2.218M in   5.008595s
      rust nil guard    489.863k (± 1.9%) i/s -      2.450M in   5.002297s
    with type safety    382.805k (± 1.7%) i/s -      1.924M in   5.028345s
        through ruru    667.268k (± 2.6%) i/s -      3.372M in   5.057512s

Comparison:
       Ruby's C impl:   683941.9 i/s
        through ruru:   667268.5 i/s - same-ish: difference falls within error
      rust nil guard:   489863.3 i/s - 1.40x  slower
     with pure input:   480551.2 i/s - 1.42x  slower
      ruby nil guard:   443185.2 i/s - 1.54x  slower
    with type safety:   382805.2 i/s - 1.79x  slower

不是Ruby或ruru的方法，而是FFI版本。现在可以看出细微变化的差别。使用ruru，能够获得C语言的性能，而不必担心编写C语言代码的相关风险。

如果一个方法没有被多次调用，那么做这些更改就不会在整体基准测试中发现任何差异。但是，对于那些被过度使用的方法，这些更改确实起了作用。

另一个关于在Ruby中对比Rust语言和C语言的有趣的事实是，CPU的缓存量可能会影响到Rust的结果。更多的CPU缓存将提高Rust的性能，可以超越C语言。

这是在FasterPath项目中，其他一些开发人员和我自己之间所观察到的信息。目前还没有对这些数据进行集中编目，但是将来应该会有一个系统做这件事。

总结

Ruru和Helix不是功能完备的系统。在ruru系统中，我观察到了在整个系统中整数，字符串和数组完美地工作，以及从ruru到Ruby的新对象的初始化过程。

在写这篇文章的时候，ruru和Helix都没有实现的一个领域是允许Ruby的垃圾收集器处理从Rust代码生成的Ruby对象。原因可能是Rust语言存在VALUE属性，但Ruby GC（垃圾收集器）不知道如何释放它。当从Rust的Pathname.entries目录条目中调用Pathname.new时发现这个问题，这导致了基准测试期间的段错误，而不是测试套件（足够在退出之前触发GC）。跟踪这个问题是ruru＃75和helix＃50。

Ruby现在已经是一种成熟的语言了，Rust语言还很年轻并在不断地发展中。ruru和Helix可能还需要一段时间才能完全兼容Ruby。这一切都取决于社团的发展和参与。

未来是如此美好。与此同时，已经有了大量可以完成的工作。鼓励大家涉足这些强大的领域，分享所学到的东西，为他人和将来的自己做好文档，不久的将来，会让年轻的开发人员更好地实现他们在性能编程方面的目标。

---

PS：最后给大家推荐一个数据库在线峰会，嘉宾来自阿里巴巴、腾讯、微博、网易等多家企业的数据库专家及高校研究学者，将围绕Kubernetes、MySQL、PostgreSQL、Redis等热点数据库技术展开。峰会详情页：http://edu.csdn.net/huiyiCourse/series_detail/74