這篇文章主要介紹了我是如何把ruby gem contracts.ruby速度提升10倍的。

contracts.ruby在我項目里用來添加代碼合約（code contracts）到Ruby中。看起來差不多是這樣的：

Contract Num, Num => Num
def add(a, b)
 a + b
end

只要add方法被調(diào)用，參數(shù)和返回值都會被檢查。

20秒

本周末，我對該庫進行了測試，發(fā)現(xiàn)其性能非常糟：

這是在隨機輸入下，運行1000次以后的結(jié)果。

所以，當給一個函數(shù)加入合約功能后，運行速度明顯下降（約40倍這樣），對此，我進行了深入的研究。

8秒

我取得了較大的進展，當傳遞合約時，我調(diào)用success_callback函數(shù)，該函數(shù)是個空函數(shù)，下面是這個函數(shù)的整個定義：

def self.success_callback(data)
end 

原來函數(shù)調(diào)用在Ruby中是非常昂貴的，僅刪除這個調(diào)用，就節(jié)省了8秒鐘：

刪除其它一些附件函數(shù)的調(diào)用，時間花費開始從9.84-> 9.59-> 8.01秒，該庫的速度馬上提升到以前的兩倍了。

現(xiàn)在，事情變的有點復(fù)雜了。

5.93秒

這里有許多年種定義一個合約的方式：匿名（lambdas）、類 （classes）、簡單舊數(shù)據(jù)（plain ol' values）等。 我有個很長的case語句，用來檢測合約的類型。在此合約類型基礎(chǔ)之上，我可以做不同的事情。通過把它改為if語句，我節(jié)約了一些時間，但每次調(diào)用這個函數(shù)時，我仍然耗費了不必要的時間在仔細檢查這個判定樹上面：

if contract.is_a?(Class)
 # check arg
elsif contract.is_a?(Hash)
 # check arg
...

當定義合約和構(gòu)建lambda時，對樹只做一次檢查：

if contract.is_a?(Class)
 lambda { |arg| # check arg }
elsif contract.is_a?(Hash)
 lambda { |arg| # check arg }

然后，我將完全繞過邏輯分支，通過將參數(shù)傳遞給預(yù)計算的lambda來進行驗證，這樣就節(jié)約了1.2秒時間。

預(yù)計算一些其它的If語句，差不多又節(jié)省了1秒時間：

5.09秒

將.zip轉(zhuǎn)換為.times又為我節(jié)省了1秒時間：

結(jié)果證明：

args.zip(contracts).each do |arg, contract|

上面的代碼要比下面這個慢：

args.each_with_index do |arg, i|

要比下面這個更慢：

args.size.times do |i|

.zip要花費不必要的時間復(fù)制和創(chuàng)建新的數(shù)組。而我認為，.each_with_index之所以慢，是因為它受制于背后的.each，所以它涉及到兩個限制而不是一個。

4.23秒

下面再看些細節(jié)的東西，contracts庫在工作時，它會為每一個方法添加class_eval（class_eval要比define_method快）的新方法，這個新方法里有一個對老方法的引用，當調(diào)用新方法時，它會檢查參數(shù)，然后根據(jù)參數(shù)調(diào)用老方法，然后再檢查返回值，并且返回值。所有這些都會調(diào)用Contract class的check_args和check_result兩個方法。我取消了這兩個方法的調(diào)用，并且對新方法進行正確檢查，結(jié)果又節(jié)省了0.9秒：

2.94秒

在上面，我已經(jīng)解釋了如何基于Contract類型創(chuàng)建lambda，然后使用這些來檢驗參數(shù)。現(xiàn)在，我換了種方法，用生成代碼來替代，當我使用class_eval創(chuàng)建新方法時，它就會從eval中獲得結(jié)果。一個可怕的漏洞，但它避免了一大堆方法調(diào)用，并且節(jié)省了1.25秒：

1.57秒

最后，我改變了調(diào)用重寫方法的方式，我先前是使用引用：

# simplification
old_method = method(name)= method(name)

class_eval %{%{
  def #{name}(*args)def #{name}(*args)
    old_method.bind(self).call(*args).bind(self).call(*args)
  endend
}}

我進行了修改，并使用alias_method方法：

alias_method :"original_#{name}", name:"original_#{name}", name
class_eval %{%{
  def #{name}(*args)def #{name}(*args)
    self.send(:"original_#{name}", *args)self.send(:"original_#{name}", *args)
   endend
}}

驚喜，又節(jié)省了1.4秒。我不知道為什么aliaa_method會如此地快，我猜是因為它跳過了一個方法的調(diào)用和綁定到.bindbind。

結(jié)果

我們成功的將時間從20秒優(yōu)化到1.5秒，我不認為還有比這更好的結(jié)果的了。我所編寫的 這個測試腳本表明，一個被封裝過的add方法要比常規(guī)的add方法慢3倍，所以這些數(shù)字已經(jīng)足夠好了。

想要驗證上面的結(jié)論很簡單，大量的時間花在調(diào)用方法上是只慢3倍的原因，這里有個更現(xiàn)實的例子：一個函數(shù)讀一個文件100000次：

稍微慢了點！add函數(shù)是個例外，我決定不再使用alias_method方法，因為它污染了命名空間，并且這些別名函數(shù)會到處出現(xiàn)（文檔、IDE的自動完成等）。

其它原因：

    在Ruby中調(diào)用方法很慢，我喜歡將代碼模塊化和重復(fù)使用，但或許是時候?qū)⒏嗟拇a進行內(nèi)聯(lián)了。
    測試你的代碼！刪掉一個簡單的未使用的方法時間從20秒縮短到了12秒。

其它嘗試

1.方法選擇器

Ruby 2.0里缺少方法選擇器這一特性，否則你還可以這樣寫：

class Foo Foo
 def bar:beforedef bar:before
  # will always run before bar, when bar is called# will always run before bar, when bar is called
 endend

 def bar:afterdef bar:after
  # will always run after bar, when bar is called# will always run after bar, when bar is called
  # may or may not be able to access and/or change bar's return value# may or may not be able to access and/or change bar's return value
 endend
endend

這樣可能會更加容易編寫decorator，并且運行速度也會加快。

2.關(guān)鍵字old

Ruby 2.0里缺乏的另一特性是引用重寫方法：

class Foo Foo
 def bardef bar
  'Hello''Hello'
 endend
end end 

class Fooclass Foo
 def bardef bar
  old + ' World'+ ' World'
 endend
endend

Foo.new.bar # => 'Hello World'Foo.new.bar # => 'Hello World'

3.使用redef重新定義方法：

Matz曾說過：

    為了消除alias_method_chain，我們引入了Module#prepend，prepend前面加#號，這樣就沒機會在語言里加入冗余特性。

所以如果redef是冗余特征，也許prepend可以用來寫decorator？

4.其它實現(xiàn)

目前為止，這些都已經(jīng)在YARV做過測試。