プロと読み解く Ruby 2.6 NEWS ファイル

技術部の笹田(ko1)と遠藤(mame)です。クックパッドで Ruby (MRI: Matz Ruby Interpreter、いわゆる ruby コマンド) の開発をしています。お金をもらって Ruby を開発しているのでプロの Ruby コミッタです。

もうすぐ Ruby 2.6 がリリースされますね! Ruby 2.6 の新機能は何だろう、と調べるためには、ソースコードの diff を見ればいいのですが、膨大な変更があるので、一つ一つ見ていくのは大変です。

$ git diff --compact-summary origin/ruby_2_5
...
 6404 files changed, 228441 insertions(+), 97984 deletions(-)

そこで、NEWS ファイルという、主要な変更点をまとめたファイルが用意されています。これを見るだけで、Ruby 2.6 の変更点が把握できます。NEWS ファイルは Ruby 2.6 の tarball などに入っています。

ただ、NEWS ファイルも、あまり詳細は書いていないため、読みづらいかも知れません。淡々と、「このメソッドが追加された」とかが並んでいるだけです。

そこで、本記事では Ruby 2.6 の NEWS ファイルの内容を、プロ Ruby コミッタの笹田と遠藤で解説していきます。解説記事はすでにいくつかあり、さらに出てくるだろうと思うのですが、本稿では、なぜ「そのような変更がおこなわれたか」という背景事情をなるべく書くように心がけています。

なお、NEWS ファイルに追記しているのは人間なので、当然追記忘れなどのミスがあります。そのため、これ以外にも変更があるかもしれませんが、ご容赦下さい。

See also:

(ko1) <- 以降、こんなふうに文責を明示します。

NEWS ファイルの読み方

まず、NEWS ファイルの構成について解説しておきます。

見ての通り、Markdown ではなく、RDoc フォーマットで書いてあります。まぁ、読む分には見た目の雰囲気でわかるんじゃないかと思います。

章立ては次の通りです。

  • Language changes / 言語の変更
  • Core classes updates (outstanding ones only) / 組込クラスのアップデート(主要なもののみ)
  • Stdlib updates (outstanding ones only) / 添付ライブラリのアップデート(主要なもののみ)
  • Compatibility issues (excluding feature bug fixes) / 非互換(バグ修正を除く)
  • Stdlib compatibility issues (excluding feature bug fixes) / 添付ライブラリの非互換(バグ修正を除く)
  • C API updates / C API のアップデート
  • Implementation improvements / 性能向上
  • Miscellaneous changes / その他

読めばわかると思いますが、言語の変更が最初にあって、組込クラス、標準ライブラリの仕様変更とかの話になり、最後に互換性関係ない性能向上とかで話を締めています。やっぱり、これまでの Ruby アプリが動くかどうかと言う、仕様変更が気になりますよね。

文中に出てくる [Feature #12912] といった表記は、https://bugs.ruby-lang.org/projects/ruby-trunk/issues に登録されたチケット番号になります。https://bugs.ruby-lang.org/issues/ の後ろに番号を付ければ、この場合は https://bugs.ruby-lang.org/issues/12912 とすれば、当該チケットを見ることができます。

NEWS は上記の順番で並んでいますが、本稿では、この順番は無視して、我々が重要だと思っている、もしくは興味がある変更を順に紹介していきます。でも、笹田が一番興味のある性能向上については、最後にまとめます(知らなくても使う分には問題ないですから)。

(ko1)

言語機能の改善

少し、文法などの拡張がありました。新しい文法などを使うと、古い Ruby で動かなくなるので、お気を付け下さい。

終端なしの Range が導入された

  • Endless ranges are introduced. You can use a Range that has no end, like (0..) (or similarly (0...)). [Feature #12912]

(1..) のように、終端を省略した Range が書けるようになりました。

遠藤が提案・実装しました。提案時に想定していたユースケースは、次の 3 つです。

ary[1..] #=> ary[1..-1] と同じ
    
(1..).each {|index| ... } # 1 から無限にループ

# each_with_index を 0 でなく 1 から始める
ary.zip(1..) {|elem, index| ... }

どれも、意外とスッキリ書けなくてモヤモヤしていました。終端が省略できればいいのでは、と思って実装してみたら、意外にすんなり実装できて驚きました。

他の用途としては、下限の指定を DSL 的に表現するのにも使えそうです。(この用途としては beginless range も欲しくなりますが、こちらの提案は pending となってます)

users.where(id: 10..)

(1..)(1..nil) の構文糖です。終端を nil にするかどうかは少し議論がありました。従来から書けていた nil..nil が endless になってよいのかとか。Qundef(Ruby ユーザからは見えない未定義を表す値)を使うとか、他にも選択肢はありましたが、一番直観的なものということで nil になりました。 (1..)(1...) の違いも結構議論がありました。(1..) は無限大を含む Range のように見えて数学的にはちょっと不思議、とか。しかし ary[1..]ary[1...] と書かないと行けないのは面倒なので、数学的な直感はおいといて (1..)(1...) の両方が入ることになりました。なお、これらはオブジェクトの等価性としては別(exclude フラグの有無が違う)です(ary[1..]ary[1...] は同じ結果になります)。

なお、次のように書くと syntax error になるのでご注意ください。

case id
when 10..
  puts "id >= 10"
end

これは、10.. で行が終わると、行継続になってしまうためです。when (10..) のようにカッコをつければ動きます。直すこともできたのですが、複数行に渡る Range リテラルの例が発見されたので、互換性重視で現在の挙動になりました。

(mame)

ローカル変数の shadowing 警告を削除

ブロックの引数の名前が、外のスコープのローカル変数と衝突しているとき、警告モードで実行すると警告が出ていました。

x = "str"
1.times {|x| ... }
#=> warning: shadowing outer local variable - x

この警告を取り除くことになりました。これにより、次のようなコードで警告を見なくてよくなりました。

user = users.find {|user| cond(user) }
#=> warning: shadowing outer local variable - user ← 2.6 で消えた

歴史的な話をすると、Ruby 1.8 ではこういう衝突があるとき、外のローカル変数を上書きしていたのですが、1.9 から現在の挙動に変わりました。

x = "str"
(0..10).each {|x| }
p x #=> 10    (in Ruby 1.8)
#=> "str" (in Ruby 1.9+)

この警告はその非互換を伝えるために存在しましたが、さすがにもう要らなそうだし、妥当なコードでも警告されてしまうのが邪魔であるということで、消すことになりました。もしこの警告が欲しい人は、Rubocop の Lint/ShadowingOuterLocalVariable を使うといいんじゃないでしょうか。

(mame)

rescue のない else が禁止

  • else without rescue now causes a syntax error. [EXPERIMENTAL] [Feature #14606]

例外処理の構文 begin ... rescue ... end には、例外が投げられなかったときの処理を書く else 節があります。

begin
  ...
rescue
  # 例外が投げられた場合
else
  # 例外が投げられなかった場合
end

rescue 節は何個書いてもよいのですが、0 個でもよかったのでした。

begin
  ...
else
  ...
end

が、このプログラムは意味がなく、理解もしにくいだろうということで、rescue 節 0 個のときは SyntaxError とすることになりました。同様に、メソッド内での rescue 無し else も禁止になりました。

def foo
  ...
else
  ...
end

個人的には、変なコードが書けなくなったので少しだけ残念な気持ちです。

(mame)

定数名で非 ASCII の大文字も利用可能に

定数名は ASCII の大文字でないとダメでしたが、2.6 で Unicode の大文字も OK となりました。

class Мир
  def приветствовать
    "Привет, Мир!"
  end
end

Мはキリル文字の大文字です。

完全に余談ですが、Unicode の大文字・小文字の話題になると、「Dz」という字の話をするのがお作法です。これは D と z の 2 文字ではなく、D と z が合体した 1 つの文字です。こういう文字を、digraph、二重音字と言います。この文字には、大文字・小文字に加え、タイトルケース(先頭の文字だけが大文字)の 3 種類があります。

# 大文字
p "\u01F1" #=> DZ

# 小文字
p "\u01F3" #=> dz

# タイトルケース
p "\u01F2" #=> Dz

Ruby では、大文字とタイトルケースの両方を定数として使えます。

class DZ # OK
end
class Dz # OK
end
class dz #=> class/module name must be CONSTANT
end

ちなみに、Dz はスロバキア語、ハンガリー語などで使われるそうです(Wikipedia の記事)。digraph は Dz 以外にもいくつかあります(List of Unicode Characters of Category “Titlecase Letter”)。

(mame)

キーワード引数とオプション引数のコーナーケースを禁止

  • Non-Symbol keys in a keyword arguments hash cause an exception.

matz がみつけた、オプション引数とキーワード引数を両方受け取るときの微妙な挙動が禁止になりました *1

def foo(h = {}, key: :default)
  p [h, key]
end

foo(:key => 1, "str" => 2)
  #=> [{"str"=>2}, 1] (2.5 まで)
  #=> non-symbol key in keyword arguments: "str" (ArgumentError) (2.6)

Ruby 2 のキーワード引数にはいろいろ変なところがあり、Ruby 3 での作り直しが検討されています(参考:大江戸 Ruby 会議 07 『Ruby 3のキーワード引数について考える』)。この変更は、それの伏線になっているとかいないとか。

(mame)

バックトレースで原因(cause)のバックトレースも出るようになった

  • Print cause of the exception if the exception is not caught and printed its backtraces and error message. [Feature #8257]

例外処理中(rescue 文や ensure 文実行中)に、新しい例外を意図して発生させたり(下記の例の NantokaError)、意図せず発生させちゃったり(rescue 文に typo があったりとか。例外処理のテストは網羅するのが面倒なので、よくありそうな話ですね)することがあります。そのとき、プロセス異常終了時のバックトレースの表示には、最後に発生した例外の情報しかありませんでした。ランタイムとしては、最後に発生した例外オブジェクトで、 Exception#cause というメソッドで取れることは取れるんですが、プロセス終了時のエラー表示には含まれていませんでした。

Ruby 2.6 からは、プロセスが例外で終了したとき、あがってきた例外オブジェクトに cause の情報があれば、その情報も一緒に表示するようになりました。

class NantokaError < RuntimeError
end

def my_open
  open('non_existing_file')
end

begin
  my_open
rescue Errno::ENOENT
  raise NantokaError
end

この例では、openErrno::ENOENT 例外を発生しますが、呼び出し元で NantokaError をさらに発生させています。

Ruby 2.5 では、

Traceback (most recent call last):
        1: from /home/ko1/src/ruby/trunk/test.rb:8:in `<main>'
/home/ko1/src/ruby/trunk/test.rb:11:in `rescue in <main>': NantokaError (NantokaError)

と、最後に発生させた NantokaError だけ表示しています。

Ruby 2.6 では、

Traceback (most recent call last):
        3: from /home/ko1/src/ruby/trunk/test.rb:9:in `<main>'
        2: from /home/ko1/src/ruby/trunk/test.rb:5:in `my_open'
        1: from /home/ko1/src/ruby/trunk/test.rb:5:in `open'
/home/ko1/src/ruby/trunk/test.rb:5:in `initialize': No such file or directory @ rb_sysopen - non_existing_file (Errno::ENOENT)
        1: from /home/ko1/src/ruby/trunk/test.rb:8:in `<main>'
/home/ko1/src/ruby/trunk/test.rb:11:in `rescue in <main>': NantokaError (NantokaError)

と、5行目の open が元々のエラーの原因であることを示すようになりました。

冗長になりますが、原因がわからないよりは便利だろう、ということで、導入されることになりました。Java とかで、すでにそのように表示されるようですね。

ちなみに、cause がたくさん連鎖していると、バックトレースはどんどん長くなります。また、上記例をちょっと変えて、少しメソッド呼び出しの深いところで実行してみると、

class NantokaError < RuntimeError
end

def my_open
  open('non_existing_file')
end

def foo
  bar
end

def bar
  begin
    my_open
  rescue Errno::ENOENT
    raise NantokaError
  end
end

foo

結果:

Traceback (most recent call last):
        5: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        4: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'
        3: from /home/ko1/src/ruby/trunk/test.rb:14:in `bar'
        2: from /home/ko1/src/ruby/trunk/test.rb:5:in `my_open'
        1: from /home/ko1/src/ruby/trunk/test.rb:5:in `open'
/home/ko1/src/ruby/trunk/test.rb:5:in `initialize': No such file or directory @ rb_sysopen - non_existing_file (Errno::ENOENT)
        3: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        2: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'
        1: from /home/ko1/src/ruby/trunk/test.rb:12:in `bar'
/home/ko1/src/ruby/trunk/test.rb:16:in `rescue in bar': NantokaError (NantokaError)

こんなエラー出るようになりました。これをよく見てみると、

        5: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        4: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'
        ...
        3: from /home/ko1/src/ruby/trunk/test.rb:20:in `<main>'
        2: from /home/ko1/src/ruby/trunk/test.rb:9:in `foo'

共通するこれらの行が被っていますね。Java だと共通する行は出力しないように制御するようですので、冗長な表記をやめるように、今後変更されるかもしれません。

結構面白いハックネタだと思うので、Ruby インタプリタをいじってみたい人は、挑戦してみませんか?

(ko1)

フリップフロップ構文が非推奨に

Ruby には、フリップフロップと呼ばれる、知る人ぞ知る機能がありました。条件式に 開始条件 .. 終了条件 と書くと、開始条件が成立してから終了条件が成立するまでずっと真になるという便利機能です。たぶん awk → Perl 経由で Ruby に入ったと思われます。

["a", "b", "c", "d", "e"].each do |str|
  if (str == "b") .. (str == "d")
    p str #=> "b", "c", "d" が順に表示される
  end
end

しかし、この機能は 3.0 で削除される方向になりました。2.6 では "warning: flip-flop is deprecated" という警告が出るようになりました。ちょっと残念ですね。

削除が提案された理由 [Feature #5400] が "Nobody knows them. Nobody uses them.(誰も知らない。誰も使ってない。)" という煽りだったので、若干荒れました。「誰がこんなの使うの」と思うような機能でも、誰かは使ってるんですよね。まあそれはともかく matz が消したいと言ったので、消える方向に。

遠藤が非推奨の警告を入れる作業を行ったのですが、思った以上に標準添付ライブラリやビルドスクリプトの中でフリップフロップは使われていて、消して回る対応が大変でした。実際にやってみるとわかるのですが、フリップフロップを使っているコードをフリップフロップ無しにするのは、思った以上にややこしいです。ということで、本当に消えて大丈夫なんでしょうか。

(mame)

Refinement の拡張

Refinement という、Ruby のメソッドを拡張する仕組みがあるのですが、拡張が効く部分が足りない、ということで拡張されることになりました。

Refinement 自体がすごく難しい機能であまり使うべきでは無いと思っているので(笹田個人の感想です)、ここではあんまり紹介しません。ただ、自分が Refinement を使っていて、「あれ、ここで拡張が効くはずなのになんで効かないんだろう?」ということがあれば、それはもしかしたらバグかもしれないので、ご報告頂ければ幸いです。

(ko1)

クラスやメソッドの追加・改善

いろんな変更がありました。

to_h がブロックを受け取るように

  • Array#to_h now accepts a block that maps elements to new key/value pairs. [Feature #15143]

to_h にブロックを渡すことで、キーと値を指定できるようになりました。

# 従来の to_h の使い方

["Foo", "Bar"].map {|x| [x.upcase, x.downcase] }.to_h
  #=> {"FOO"=>"foo", "BAR"=>"bar"}

# 新しい用法

["Foo", "Bar"].to_h {|x| [x.upcase, x.downcase] }
  #=> {"FOO"=>"foo", "BAR"=>"bar"}

Array の他に Enumerable や Struct なども同じように拡張されました。

この提案は過去にもあった([Feature #10208] Passing block to Enumerable#to_h)のですが、そのときは matz がリジェクトしています。しかし今回はシュッとアクセプトされました。気が変わったそうです。何度も言ってみるものですね。

(mame)

Enumerable#chain

  • Enumerable#chain returns an enumerator object that iterates over the elements of the receiver and then those of each argument in sequence. [Feature #15144]
  • Enumerator#+ returns an enumerator object that iterates over the elements of the receiver and then those of the other operand. [Feature #15144]
  • Enumerator::Chain: This is a new class to represent a chain of enumerables that works as a single enumerator, generated by such methods as Enumerable#chain and Enumerator#+.

Ruby プログラミングをしていると、イテレータをよく使います。イテレータが複数あって、それらをいっぺんに辿りたいときはどうするといいでしょうか。

例えば、配列 a1, a2, a3 があるとします。これらの要素すべてを表示する、という簡単な例を考えてみましょう。

こんな感じでしょうか。イテレータの配列を作っています。多重ループになっちゃうのがイマイチですね。

a1 = %w(1 2)
a2 = %w(3 4)
a3 = %w(5 6)
[a1, a2, a3].each{|ary| ary.each{|e| p e}}

では、配列を全部つなげてみるといいでしょうか。

(a1+a2+a3).each{|e| p e}

ただ、これはイテレータが配列の時にしかうまくいかず、また大きな配列を作ってしまうと性能悪化の懸念が生じます。

Ruby 2.6 からは、Enumerable#chain を使って、イテレータをつなげることができるようになりました。例えば、この例では、次のように書くことができます。

a1.chain(a2, a3).each{|e| p e}

Enumerator#+ を使うことで、Enumerator を同じようにつなげることができます。

(a1.each + a2.each + a3.each).each{|e| p e}

Enumerator#+each を持つメソッドならなんでも受け取るので、例えばこんなふうに書けます。

(a1.each + a2 + a3).each{|e| p e}

each を持ったオブジェクトならなんでも与えられるので、a2 だけ逆順に表示したい、といったときは、Array#reverse_eachEnumerator を返すことを利用して、こんなふうに書くことができます。

(a1.each + a2.reverse_each + a3.each).each{|e| p e}

# or
a1.chain(a2.reverse_each, a3).each{|e| p e}

Enumerator::Chain クラスは、この機能を実装するために導入されたので、まぁこのクラスの存在を気にする必要はないでしょう。

要望自体は以前からあったのですが、なんとなくペンディングになっていたのを、最近話題に取り上げたことで導入されることになりました。時々欲しくなりますよね。

最初は、Enumerator だけを対象に、Enumerator#+ だけでいいんじゃないかな、と思っていたんですが、開発者会議で議論するうちに、Enumeable#chain という、みんなが使う配列とかも影響がありそうなメソッドに発展していきました。

Enumerator#+ を使って i1 + i2 + ... と沢山足していくと、内部的に深い木構造を作ることになるので、効率の心配がありました。まぁ、何十も重ねる人は居ないと思うのですが、心配なら、Enumerable#chain(i1, i2, ...) や、Enumerator::Chain.new(i1, i2, ...) を利用するといいと思います。まぁ、居ないと思うんだけど。*2

(ko1)

Enumerator::ArithmeticSequence の導入

  • This is a new class to represent a generator of an arithmetic sequence, that is a number sequence defined by a common difference. It can be used for representing what is similar to Python's slice. You can get an instance of this class from Numeric#step and Range#step.
  • Added Range#% instance method. [Feature #14697]
  • Range#step now returns an instance of the Enumerator::ArithmeticSequence class rather than one of the Enumerator class.

Arithmetic Sequence、つまり等差数列を扱うクラスが提案されました。なんじゃこの長い名前は、誰が使うんだ、と思うかも知れませんが、生成は簡単です。

as1 = 3.step(by: 2, to: 10)

また、Range#% を使っても作ることができます(Range#step の別名として導入されました)。

as2 = (3..10)%2 # 3.step(by: 2, to: 10) と同じ

どちらも、to_a[3, 5, 7, 9] を取り出すことができます。

さて、なんでこのような等差数列が必要になるかというと、Python における スライス があると、色々と便利だそうで(笹田は、どう便利かはよく知りません)、そのため、Ruby ではどのように導入するか、ということが議論になり、最終的に Enumerator::ArithmeticSequence という形で導入されました。

Python では 3:10:2begin:end:step)のように書くそうです。(3..10)%2 は、Ruby で許される表現の中で、短く書けるのでこれでいいか、といった議論を経て導入されました(新規文法の導入も検討しましたが、そこまですることはないか、となりました)。

実は Ruby では、これを役立てるための仕組みは、まだあまり組み込まれていないため、実際に便利に使えるには、いろいろと揃ってきてからかな、と思います。例えば、配列の要素を取り出すといったことはできません(あ、MRI のハックネタですね)。

p (1..20).to_a[(1..)%3]
#=> no implicit conversion of Enumerator::ArithmeticSequence into Integer (TypeError)

例えば Python だと、こんなふうに使えます。

>>> list(range(1, 21))[1::3]
[2, 5, 8, 11, 14, 17, 20]

ちなみに、Enumerator::ArithmeticSequence には #begin#end#step メソッドがあるので、自分のライブラリをこれに対応することが可能です。

なお、Range#step は Enumerator クラスを返していましたが、この変更で Enumerator::ArithmeticSequence が返るという非互換があります。が、まぁ誰もはまらないよね、多分。

(ko1)

Kernel#yield_self の別名に Kernel#then が導入された

yield_self 便利だけど名前がね... という議論に終止符を打つべく、我らがまつもとゆきひろさんが満を持してコミットした別名then です。まつもとさんの久々のコミットでした。

then という言葉自体は、Promise などで使われていて、それと被るから良くないんじゃないの、という批判があったんですが、Matz が、まぁいいんじゃないの、ということで導入されました。新たな名前論争の種になるかもしれません。

(ko1)

Proc に関数合成オペレータ Proc#>>Proc#<< が追加

一部の方にとっては待望の、関数合成オペレータが追加されました。

Proc の f1 、f2 に対して f1 >> f2 とすると、まず f1 を呼び出し、その返り値を f2 に渡して呼び出す、という Proc を新たに作ります。f1 << f2 は逆で、f2 、f1 の順に呼び出します。次の例を見ると違いがわかると思います。

plus2  = -> x { x + 2 }
times3 = -> x { x * 3 }

times3plus2 = plus2 << times3
p times3plus2(3) #=> 3 * 3 + 2 => 11
p times3plus2(4) #=> 4 * 3 + 2 => 14

plus2times3 = times3 << plus2
p plus2times3(3) #=> (3 + 2) * 3 => 15
p plus2times3(5) #=> (5 + 2) * 3 => 21

提案自体は古くからありましたが、なかなか記号が決まらなくて pending になっていました。数学での関数合成の記号は小さい円(たとえばf ∘ g)なのですが、どちらが先に評価されるかわかりにくいことや、Unicode でないと書けないので * で代用せざるを得ないことなどで議論がまとまらないということが続いていました。

今回、Groovy が <<>> を使っている(6.3. Composition)ということが決め手となり、それにならうことになりました。上の例も Groovy のドキュメントのサンプルを翻訳したものです。

(mame)

exception オプションの導入

  • Kernel#Complex, Kernel#Float, Kernel#Integer, and Kernel#Rational take an :exception option to specify the way of error handling. [Feature #12732]
  • Kernel#system takes an :exception option to raise an exception on failure. [Feature #14386]

予想外の入力に対して、例外を起こすか、nil を返すかは、API デザインにとって難しい問題です。例えば、Array#[] は、範囲外アクセスを行うと nil を返します。Array#fetch(index) では、範囲外では例外を返します。Array#[] のほうが圧倒的に短いため、普通は Array#[] を使うと思いますが、その辺(なにをデフォルトに置くか)は言語デザインの妙なのかなと思います。

さて、Kernel#Integer(obj) は、何か obj を与えると、良い感じに整数に変換してくれるメソッドです。ただ、変換できない場合、例外を発生します。

p Integer('hello')
#=> `Integer': invalid value for Integer(): "hello" (ArgumentError)

JSON などをパースするとき、整数としてパースできるかな、という検査をするとき、このメソッドが使えそうですが、失敗時にいちいち例外が発生してしまうと、ちょっと面倒です(プログラムを書くのも面倒だし、性能が落ちてしまうのもいや)。そこで、exception: false というキーワード引数を指定することで、整数への変換に失敗すると、例外ではなく、単に nil を返すようにしました。

Integer だけでなく、Kernel#Complex, Kernel#Float, Kernel#Rational にも同様についたようですね。

似た話で、system() で実行が失敗したときに例外を発生することができるようになりました。

p system("ruby -e raise") #=> false
p system("ruby -e raise", exception: true)
#=> `system': Command failed with exit 1: ruby -e raise (RuntimeError)

(ko1)

File.read('| ...') が出来なくなった

  • File.read, File.binread, File.write, File.binwrite, File.foreach, and File.readlines do not invoke external commands even if the path starts with the pipe character '|'. [Feature #14245]

File.read('| cmd') のように実行すると、cmd の実行結果を返す、みたいな機能があったんですが、File って言ってるのにコマンド実行しちゃうのは罠だろう、ということで、例外になることになりました。

もし必要なら、 IO.read('| cmd') などを使ってください。

(ko1)

String#crypt が非推奨に

crypt(3) はなんかもう古くて脆弱なので消しましょう、ということで、2.6 では非推奨となりました。まあ、String クラスのメソッドにするのは現代から見たらやりすぎですよね。

互換レイヤとして string-crypt gem がリリースされています。

require "string-crypt"

とすれば String#crypt が利用可能になります。これを書きながら気づいたんですが、この gem は Linux でビルドできませんでした。PR を投げておいたのでお待ちください。(なお、Ruby 2.6 でも組み込みの String#crypt が消えたわけではないので、今すぐ困ることはないはずです)

(mame)

Time オブジェクトのタイムゾーンを指定できるように

  • Time.new and Time#getlocal accept a timezone object as well as a UTC offset string. Time#+, Time#-, and Time#succ also preserve the timezone. [Feature #14850]

タイムゾーンを指定した Time オブジェクトを作る方法が環境変数経由しか無かった(びっくり!)ということで、API が追加されました。

Time.new(2018, 12, 25, 0, 0, 0, tz)

tz として渡すオブジェクトは、local_to_utcutc_to_localutc_offset の 3 つのメソッドを実装している必要があるらしいです。

追記(2018/12/25 15:58):local_to_utcutc_to_local が必須、abbrname があると望ましいらしいです。 (mame)

Array#unionArray#difference

それぞれ、Array#|(和集合)と Array#-(差集合)の別名です。

p [1, 2, 3].union([2, 3, 4])      #=> [1, 2, 3, 4]
p [1, 2, 3].difference([2, 3, 4]) #=> [1]

となると Array#& の別名の Array#intersection もありそうなものですが、こちらは導入されていません。なぜなら要望が来なかったので(貢献チャンスかも?)。

追記(2018/12/25 12:33):単なる別名ではなく、任意個の引数がとれるという微妙な違いがありました。

(mame)

Array#select の別名として Array#filter が追加

select の別名です。

[1, 2, 3, 4, 5].filter {|n| n.odd? } #=> [1, 3, 5]

filter というと、該当するものを残すのか(select と同じ)、それとも消すのか(reject と同じ)、曖昧だという声もありましたが、他の言語では残すのが多そうということで、select と同じということになったようです。

#filter!#select! の別名として追加されています。Array 以外に Enumerable や Hash なども同様に追加されてます。

(mame)

Binding#source_location の追加

Binding が作られたファイル位置を返すメソッドが追加されました。[Feature #14230]

# test.rb
bndg = binding # ここは 2 行目

p bndg.source_location #=> ["test.rb", 2]

これには中々面倒くさい背景があります。

現在、eval 内で例外が発生すると、binding 引数由来のファイル名や行番号を表示してしまいます。

bndg = binding # ここは 1 行目

eval(<<END, bndg)
  def foo  # bndg 基準では 1 行目
    raise  # bndg 基準では 2 行目
  end
END

foo #=> Traceback (most recent call last):
    #       1: from test.rb:9:in `<main>'
    #   test.rb:2:in `foo': unhandled exception

例外のスタックトレースを見てください。2 行目で例外が発生したと言われています。しかし、このファイルの 2 行目を見ると、空行です。びっくり。この問題を避けるために、evalbinding 引数の生成元のファイル名や行番号を利用しないようにしよう、ということになりました。[Bug #4352]

しかしこの変更を実際に試したところ、eval("[__FILE__, __LINE__]", bndg) として Binding の生成元のファイル名や行番号を取り出すというイディオムが pry など一部のプログラムで利用されていることが発覚しました。このイディオムはあまり推奨されるものでもないので、この情報をより明示的に取り出す手段の Binding#source_location を導入し、世の中のプログラムではこちらを使うように変えてもらう期間を置くことにしました。

なお、Ruby 2.6 でこのイディオムを警告ありモードで実行すると、警告が出るようになっています。

$ ./ruby -w
eval("[__FILE__, __LINE__]", binding)
-:1: warning: __FILE__ in eval may not return location in binding; use Binding#source_location instead
-:1: warning: __LINE__ in eval may not return location in binding; use Binding#source_location instead

(mame)

Dir#each_child

Ruby 2.5 で導入された、ディレクトリの中を探る(ただし、., .. は列挙しない) Dir.childrenDir.each_child というクラスメソッドはあるけど、Dir.open で生成する Dir インスタンスで使える Dir#each_childDir#children はないから入れましょう、という提案で、「そうだね」とすんなり入りました。

こういう、「そうだね」という提案ばかりだと楽なんですが。

(ko1)

Exception#full_message に highlight, order キーワード引数がついた

  • Exception#full_message takes :highlight and :order options. [Bug #14324]

まぁ、書いてあるとおりなのですが、引数がつきました。そもそも、Exception#full_message とは、って感じですが、ログとかに出力するため、文字列でバックトレース表記(+エラー原因)を出力するために Ruby 2.5 で導入されたものです。これに、いろいろカスタマイズするオプションがついた感じです。

(ko1)

Hash#merge#merge! が任意個の引数を受け取るようになった

  • Hash#merge, Hash#merge!, and Hash#update now accept multiple arguments. [Feature #15111]

Hash#merge が任意個の引数を受け取るようになりました。h1.merge(h2).merge(h3) と書かなくて良くなります。

h1 = { 1 => 1 }
h2 = { 2 => 2 }
h3 = { 3 => 3 }
h1.merge(h2, h3) #=> { 1=>1, 2=>2, 3=>3 }

クックパッドが開催した、Ruby をハックしてみようというイベント Cookpad Ruby Hack Challenge #5 の参加者の方が提案して、作成したパッチが取り込まれました。めでたいですね。Ruby Hack Challenge は、今後もちょくちょく開催すると思うので、貢献してみたい人はぜひご参加ください。

(mame)

open のモードに修飾子 "x" が追加

  • Added new mode character 'x' to open files for exclusive access. [Feature #11258]

Kernel#open などのモードに "x" という修飾子が追加されました。"w" と組み合わせて使うと、ファイルをうっかり上書きしなくて済むようになります。

open("file", "w")  # file を作って開く(すでに file があったら上書き)
open("file", "wx") # file を作って開く(すでに file があったら例外)

(mame)

KeyError 発生原因の receiverkey を Ruby レベルで指定可能に

  • KeyError.new accepts :receiver and :key options to set receiver and key in Ruby code. [Feature #14313]

Ruby 2.5 から、KeyError が発生したときのレシーバとキーが KeyError インスタンスから参照できるようになっています。

begin
  { 1 => 2 }.fetch(:foo)
rescue KeyError => e
  p e.key      #=> :foo
  p e.receiver #=> {1=>2}
end

このように、組み込みの Hash#fetch は内部的にこれらの情報を設定していたのですが、Ruby レベルで投げる例外にこの情報を設定することができませんでした。2.6 では、次のようにできるようになりました。

raise KeyError.new(receiver: recv, key: key)

NameErrorNoMethodError でも、同様に receiver が指定できるようになりました。

(mame)

Module#method_defined? とかが inherited オプショナル引数を受けるようになった

  • Module#method_defined?, Module#private_method_defined?, and Module#protected_method_defined? now accept the second parameter as optional. If it is +true+ (the default value), it checks ancestor modules/classes, or checks only the class itself. [Feature #14944]

細かい話です。

Module#instance_methods は、inherited オプショナル引数を受け取ることができます。デフォルトは true ですが、false にすると、クラスの継承木を辿らないで、そのクラス・モジュールだけ調査します。

p String.instance_methods(true).size   #=> 183
String.ancestors.each{|c|
  p [c, c.instance_methods(false).size]
}
#=>
# [String, 128]
# [Comparable, 7]
# [Object, 0]
# [Kernel, 50]
# [BasicObject, 8]
# 合計 193 ... あれ、あわないよ?
# というのは、10個ほど、重複するメソッドがあるからです(多分)。
# ちなみに、String の 128 個というのはキリが良いですね。

このように、いくつかのメソッドには、inherited オプショナル引数を取りますが、似たようなメソッドで、それを取らないものがあったので、似たようなもの全部に入れてしまえばいいのでは、という提案があって、イイネイイネと入りました。

(ko1)

Object#=~ が非推奨に

Object#=~ が非推奨になりました。と言うとびっくりするかもしれませんが、String#=~Regexp#=~ は残るので、gets =~ /regexp/ みたいな普通のマッチングは引き続き可能なので、ほとんど影響はないはずです。

Object#=~ は、引数にかかわらず常に nil を返すという、あまり用途のわからないメソッドでした(導入経緯も調べたのですが、古すぎてよくわかりませんでした)。

p(1 =~ 1) #=> nil

用途がわからないだけでなく、運が悪いとバグを隠すことがあった(次のような例)ので、非推奨ということになりました。

s = ["foo"] # 文字列のつもりだったのに、うっかり文字列の配列にしてしまった
if s =~ /foo/
  puts "マッチしない……なぜ……"
end

なお、nil はマッチング対象にしたいことがある(たとえば ENV['non_existing'] =~ /regexp/)ということで、NilClass#=~ は新たに導入されました。

Object#=~ と対になる Object#!~ は、非推奨になっていません。!~=~ を呼び出してその返り値の not をとって返すので、自分のクラスに =~ だけを定義するというプログラムが存在します。そういうプログラムは完全に無実であること、また !~ が残っていても =~ がなければ結局 NoMethodError になるだけで実害はないことから、そのまま残されることになりました。

(mame)

Random.bytes が導入

ちょっとした便利メソッドです。

p Random.bytes(3) #=> "\xCF\xB5\xF4"

提案チケットは 2011 年に登録されていて、非常に長い間放置されていました。遠藤が古いチケットを整理しているときに見つけたので、開発者会議の議題にあげて無事採択されました。つまり遠藤がえらい。

(mame)

String#split がブロックを受け取るように

  • String#split yields each substring to the block if given. [Feature #4780]

String#split にブロックを渡すと、区切られた各断片が yield されてくるようになりました。

"foo/bar/baz".split("/") {|s| p s } #=> "foo", "bar", "baz"

これも 2011 年からほったらかしだったチケットを掘り起こした成果です。えらい。

(mame)

Unicode のバージョンが 10.0.0 から 11.0.0 に

  • Update Unicode version from 10.0.0 to 11.0.0. [Feature #14802] This includes a rewrite of the grapheme cluster (/\X/) algorithm and special-casing for Georgian MTAVRULI on String#downcase.
  • Update Emoji version from 5.0 to 11.0.0 [Feature #14802]

Unicode のバージョンが上がったようです。あと Emoji も。正直よくわからないのですが、たとえばジョージア語の大文字が導入されたそうです。

p "ლალი".upcase #=> "ლალი" in 2.5
                 #=> "ᲚᲐᲚᲘ" in 2.6

(mame)

Ruby の抽象構文木を取り出す実験 API が導入

  • RubyVM::AbstractSyntaxTree class is added.
  • RubyVM::AbstractSyntaxTree.parse parses a given string and returns AST nodes. [experimental]
  • RubyVM::AbstractSyntaxTree.parse_file parses a given file and returns AST nodes. [experimental]

なぜか結構話題の、抽象構文木を取り出す API が実験的に導入されました。

ast = RubyVM::AbstractSyntaxTree.parse("1 + 2 * 3")

pp ast #=>
# (SCOPE@1:0-1:9
#  tbl: []
#  args: nil
#  body:
#    (OPCALL@1:0-1:9 (LIT@1:0-1:1 1) :+
#       (ARRAY@1:4-1:9
#          (OPCALL@1:4-1:9 (LIT@1:4-1:5 2) :*
#             (ARRAY@1:8-1:9 (LIT@1:8-1:9 3) nil)) nil)))

RubyVM::AbstractSyntaxTree#children を使うと、サブツリーを取り出せます。

pp ast.children[2] #=>
# (OPCALL@1:0-1:9 (LIT@1:0-1:1 1) :+
#    (ARRAY@1:4-1:9
#       (OPCALL@1:4-1:9 (LIT@1:4-1:5 2) :* (ARRAY@1:8-1:9 (LIT@1:8-1:9 3) nil))
#       nil))

RubyVM::AbstractSyntaxTree.parse_file なんてのもあります。

さて、この API がどういうときに便利かと言うと、実際のところ、そんなに便利ではないと思います。というのも、この抽象構文木は、MRI の評価器の実装に結びついてて読み解くのは難しいし、もちろんドキュメントは無いし、今後の Ruby のバージョンアップで説明なく非互換な変更が入っていくし、微妙に最適化っぽい変換がされててソースとの対応が取りにくいし、という感じで、一般ユーザがカジュアルに使うものではないです(RubyVM という名前空間にあるものは、そういうプロユースのものです)。想定用途は、Ruby 本体のデバッグやテスト、Ruby のバージョンアップに食いついていく覚悟のあるプログラム(たとえば静的解析器とか)などです。普通に Ruby の抽象構文木で遊びたい人は、たぶん parser gem を使うのがよいと思います。

(mame)

RubyVM::AbstractSyntaxTree.of

  • RubyVM::AbstractSyntaxTree.of returns AST nodes of the given proc or method. [experimental]

メソッドオブジェクトや Proc オブジェクトから抽象構文木オブジェクトを取り出す API です。

def f
  1 + 2 + 3
end

pp RubyVM::AbstractSyntaxTree.of(method(:f))
#=> (SCOPE@2:0-4:3
#    tbl: []
#    args:
#      (ARGS@2:5-2:5
#       pre_num: 0
#       pre_init: nil
#       opt: nil
#       first_post: nil
#       post_num: 0
#       post_init: nil
#       rest: nil
#       kw: nil
#       kwrest: nil
#       block: nil)
#    body:
#      (OPCALL@3:2-3:11
#         (OPCALL@3:2-3:7 (LIT@3:2-3:3 1) :+ (ARRAY@3:6-3:7 (LIT@3:6-3:7 2) nil))
#         :+ (ARRAY@3:10-3:11 (LIT@3:10-3:11 3) nil)))

これはもう完全な闇 API です。というのも Ruby インタプリタは、読み込んだソースコードをバイトコードにコンパイルし終えた後は、ソースコード文字列も抽象構文木も捨ててしまうので、本来この抽象構文木は取り出しようがないはずのものです。どのようにしているかと言うと、

  • パース時に、すべてのノードに番号を振っておく
  • 抽象構文木のコンパイル時に、元ソースファイル名やルートノードのノード番号をバイトコードに書き加えておく
  • RubyVM::AbstractSyntaxTree.of が呼ばれたら、メソッドオブジェクトなどのバイトコードが持つ元ソースファイル名とノード番号を引っ張り出す
  • ソースファイルをもう一度開いて、読み込み、パースし直して、対応するノード番号のサブツリーを特定し、抽象構文木オブジェクトとして返す

というハックになっています。なので、ソースファイルの中身が変わっていたり、ソースコードを標準入力などで流し込んだ場合は、RubyVM::AbstractSyntaxTree.of は使えません。闇ですよね。覚悟なしに使わないでください。

(mame)

RubyVM.resolve_feature_path

  • RubyVM.resolve_feature_path identifies the file that will be loaded by require(feature). [experimental] [Feature #15230]

require は、(1) 読み込むファイルのパスを特定する、(2) そのファイルを読み込んで実行する、の 2 段階を行いますが、RubyVM.resolve_feature_path は (1) だけをやる API です。

静的解析を作るときにほしいなーという気分だったのでとりあえず作ってみました。RubyVM の名前空間にある通り、一般ユーザが使うことは想定されていません。もし何か用途があったら、ちゃんとした API として導入することも検討できると思うので、教えてください。

(mame)

TracePoint の拡張

いろいろ便利だったり悪用できたりする TracePoint ですが、いくつか拡張がありました。そもそも、使う人が居なさそうなのに、さらに複雑な拡張が入ったので、普通の人は気にしないでいいと思います。普通じゃない人には待望の機能です。

まず、TracePoint#enable で、target: キーワード引数が導入され、フックを有効にする場所を指定することができるようになりました。

TracePoint(と、その前身となった set_trace_func)は、フックを登録すると、すべての場所でフックが呼ばれるようになります。例えば、あるファイルのある行を実行したときだけ、フックを実行したい、というケースを考えます。つまりブレイクポイントですね。これまでは、フックの中で場所(ファイル名と行番号)を確認する、ということを行っていました。ちょっと考えるだけでも非効率です。TracePoint#enable(target:) を指定することで、本当にフックが欲しいところだけでチェックできるようになりました。

次に、新イベントscript_compiled に対応しました。スクリプトをバイトコード(MRI用語では ISeq: InstructionSequence、命令列)にコンパイルしたタイミングで呼ばれます(ついでに便利メソッドがいくつか増えています)。

この新イベントと TracePoint#enable(target:) を組み合わせることで、(例えば)ブレイクポイントが便利に実装できることになります。

なお、TracePoint の拡張については、後日改めてまとめます。

追記:まとめました。

techlife.cookpad.com

(ko1)

ライブラリの変更

あまり詳しくないので、わかるところだけピックアップしてご紹介します。

Bundler の同梱

Bundler がついに、Ruby と一緒にインストールされるようになりました。もう、gem i bundler としなくてもよくなります。

今後 rubygems と少しずつ統合が進んでいくそうです。

(ko1)

oneshot coverage の導入

  • A oneshot_lines mode is added. [Feature #15022] This mode checks "whether each line was executed at least once or not", instead of "how many times each line was executed". A hook for each line is fired at most once, and after it is fired the hook flag is removed, i.e., it runs with zero overhead.

コードカバレッジ測定機能に、oneshot coverage という新モードを追加しました。 これは、各行の実行回数ではなく、各行が1回でも実行されたかどうかを記録するものです。

oneshot coverageについては、明日詳説する記事を書く予定です。

追記(2018/12/26 10:46):書きました。

techlife.cookpad.com

(mame)

FileUtils#cp_lr

ディレクトリの中の全ファイルを再帰的にハードリンクしていくメソッドです。cp -r と似ていますが、コピーの代わりにハードリンクをします。

2010 年に提案されていて放置されていたチケット [Feature #4189] をチケット整理で掘り起こした成果です。えらい。

(mame)

Matrix の拡張

Matrix が交代行列かどうかを判定する Matrix#antisymmetric? が追加

  • Matrix#antisymmetric?, Matrix#skew_symmetric?

交代行列とは、転置して符号反転させたら元の行列と一致する行列のことです。日本語で言うとややこしいですが、行列 mm.t == -m を満たすなら交代行列です。

これを判定するメソッド antisymmetric? が追加されました。skew_symmetric? という別名も入っています。

以下、どうでもよい話。このメソッドにはなかなかややこしい経緯がありました。このメソッドはそもそも、反対称関係(antisymmetric relation)の行列表現の判定として提案され、取り込まれました。しかし、反対称関係の行列表現とは別に、反対称行列(antisymmetric matrix、日本語では交代行列)という概念があります。Matrix#antisymmetric? という名前なので、「反対称行列の判定がなにかおかしい」というバグ報告が来て、現在の挙動に変わりました。しかし不幸なことに、この行列は数学の分野ではあまり反対称行列とは言わず、歪対称行列(skew-symmetric matrix)と言います(ただし、物理学の世界では antisymmetric matrix が普通らしい)。ということで Matrix#skew_symmetric? の別名も追加されました。なお、日本語では交代行列ということが多いですが、英語で alternating matrix とはどの分野でもあまり言わないようです(ゼロでもないみたいですが)。名前がこんがらがると不幸が起きるという例でした。

(mame)

Matrix の破壊的更新が可能に

  • Matrix#map!, Matrix#collect! [Feature #14151]
  • Matrix#[]=
  • Vector#map!, Vector#collect!
  • Vector#[]=

Matrix#[]= で要素の破壊的更新ができるようになってしまいました。[Feature #14151]

Matrix#map!#collect!Vector#map!#collect!Vector#[]=なども入っています。

個人的に、Matrix みたいな数の一種が破壊的に更新可能なのはとても違和感があるのですが。Matlab とかの方から来た人は、更新したくなるようです。

(mame)

性能向上

最後に、みんな大好き性能向上の話です。本章の執筆は全て笹田 (ko1) が担当します。

MJIT

  • Introduce an initial implementation of JIT (Just-in-time) compiler. [Feature #14235] [experimental]

MJIT という JIT コンパイラが導入されました。Ruby 2.6 の目玉ですね。

私が何か説明するよりも、国分さんの解説記事(Ruby 2.6のJITで実装か検討を行なった最適化集 - Qiita)や発表資料( https://speakerdeck.com/k0kubun )などを見て貰うのが正確で良いと思います。他の人も沢山解説記事を書いているようですし。

現状では、バイトコード実行することによるオーバヘッドを、MJIT によって削減する、といった程度の効果なので、すごく劇的に性能向上、というレベルではありません。いろいろな理由で、Rails での性能向上も、まだ難しいでしょう(他人の仕事には厳しい)。今後、どこまで速くなるか楽しみですね。

Proc まわりの性能向上

ブロックパラメータで渡された Proc#call で呼んでも速い

  • Speedup block.call where block is passed block parameter. [Feature #14330] Ruby 2.5 improves block passing performance. [Feature #14045] Additionally, Ruby 2.6 improves the performance of passed block calling.

Proc まわりでは、def foo(&b); ... baz(&b) のように、渡されたブロックを、別のメソッドに単に渡すだけなら、Proc オブジェクトをわざわざ作らないので速くなる、というハックを Ruby 2.5 で導入しました(Ruby 2.5 の改善を自慢したい)。Ruby 2.6 では、その続きで、もう少しいろいろしています。

大抵、&b と渡ってきたブロックは、yield じゃなくて b.call って呼びたくなると思うんですが、Ruby 2.5 では、結局ここで(b を参照した時点で)Proc オブジェクトを生成してしまので、遅いという問題がありました。

Ruby 2.6 では、ちょっと工夫して(説明が面倒なので詳細割愛)、Proc を生成しなくても済むようになりました。チケットにはどれくらい高速になったか書いていないのですが、下記のベンチマークで試してみると、

Benchmark.driver{|x|
  x.executable name: 'ruby 2.5', command: %w'/home/ko1/ruby/install/ruby_2_5/bin/ruby'
  x.executable name: 'ruby 2.6', command: %w'/home/ko1/ruby/install/trunk/bin/ruby'

  x.prelude %q{
    def foo(&b); b.call; end
    def bar(); yield; end
  }
  x.report 'b.call', %q{
    foo{}
  }
  x.report 'yield', %q{
    bar{}
  }
}
Warming up --------------------------------------
              b.call     2.719M i/s -      2.815M times in 1.035435s (367.78ns/i)
               yield    13.591M i/s -     13.646M times in 1.004094s (73.58ns/i, 272clocks/i)
Calculating -------------------------------------
                       ruby 2.5    ruby 2.6
              b.call     3.451M     12.293M i/s -      8.157M times in 2.363882s 0.663573s
               yield    15.725M     19.970M i/s -     40.772M times in 2.592803s 2.041643s

Comparison:
                           b.call
            ruby 2.6:  12292769.5 i/s
            ruby 2.5:   3450742.9 i/s - 3.56x  slower

                            yield
            ruby 2.6:  19970380.1 i/s
            ruby 2.5:  15725212.8 i/s - 1.27x  slower

こんな結果になり、この環境だと Ruby 2.5 と比べて 3.56 倍くらい速いようです。 ただ、やっぱりまだ yield よりは遅いですね。もうちょと頑張って欲しい。しかし、なんで Ruby 2.6 で yield こんなに速いんだろう。

$SAFE を一部諦めて Proc#call を高速化

  • Speedup Proc#call because we don't need to care about $SAFE any more. [Feature #14318] With +lc_fizzbuzz+ benchmark which uses Proc#call many times we can measure x1.4 improvements. [Bug #10212]

$SAFE という古の機能があるのですが(何の機能かはググってね)、この仕様の一部をこっそり削って、Proc#call が高速になりました。たくさん Proc#call を実行するベンチマークでは、1.4 倍の速度向上が得られたようです。やったね。

具体的に何をしたかというと、Proc#call を呼び出した時の $SAFE を保存しておいて、Proc#call が終了したとき、必ず保存しておいた状態に戻す、という仕様があったんですが、それを撤廃しました。戻すだけなら簡単じゃん、と思うかもしれませんが、「必ず戻す」というのがくせ者で、例外時などでも戻せるように、いろいろ準備が要るのでした。

ただ、そもそも $SAFE を誰も利用しないので、この値を戻す必要がないことが大半で、無駄な努力でした。と言う事情を開発者会議で説明すると、「じゃあやめよう」とすんなりやめることになりました。そのため、元に戻すための諸々のコードが不要になり、軽量になりました。

VM生成系の一新

  • VM generator script renewal; makes the generated VM more optimized. [GH-1779]

VM 生成系と言われてもよくわからないと思いますので、ちょっと解説します。

現在の MRI の仮想マシンは、直接ソースコードを全部書くわけではなく、insns.def というファイルに、命令定義が記述してあります。このファイルを、ある Ruby スクリプトを通すことで、C のソースコードに変換し、それを使って MRI バイナリが完成します。つまり、Ruby のビルドには Ruby が必要です。この「ある Ruby スクリプト」が VM 生成系です。

で、この VM 生成系なんですが、私が10年以上も前に、1ファイルに汚く書き散らしていたモノを Ruby 2.5 までは使っていました。それを今回卜部さんがモダンな感じにファイルを分割したりして整理してくれました。これで、さらに insns.def ファイルに情報を入れやすくなりました。

ということで、すでに最適化に必要な情報を入れたりして VM の実行がいくらか高速化されています。何もしなくても、Ruby 2.6 にバージョンアップするだけで数%速くなる、かもしれません。

スレッドキャッシュの有効化

  • Thread cache enabled for pthreads platforms (for Thread.new and Thread.start). [Feature #14757]

スレッドのキャッシュが有効化されました。ってだけだとわかんないですよね。

Ruby(MRI)のスレッドはネイティブスレッドと1対1対応なので、Thread.new{...} でスレッドを作成すると、OS などが提供するネイティブスレッドの生成が必要になります。例えば、POSIX Thread が利用できる環境では、Ruby は POSIX Thread を pthread_create() 関数を用いて作るのですが、これが重い(ことが多い。実装方法によります)。例えば、Linux では重い。

そこで、このパッチでは、終了して使わなくなった POSIX Thread は少しの間キャッシュしておいて、また Thread.new{...} でスレッドを生成したら、そのキャッシュされたものを使う、というものになります。ベンチマークによっては 70 倍程度速くなったそうです。スレッドを作っては捨て、と繰り返すような、ちょっと特殊かも知れない処理ですね。

なお、「少しの間」というのは、5秒間のようです。

3rd party library が TLS (Thread Local Storage) を用いて、初期値に依存していたりすると、もしかしたらまずいことが起こるかも知れません(再利用されたときは、初期値は前のスレッドの値が残っているため)。もし、そういう例を知っていたら教えてください。

タイマースレッドを不用に

  • timer thread is eliminated for platforms with POSIX timers [Misc #14937]

スレッドを扱うために、インタプリタ内部で、タイマースレッドというものを利用していました。タイマースレッドのために、Ruby プロセスを起動すると、かならず(メイン処理用のスレッドとあわせて)2 つネイティブスレッドを作るようになっていました。

Ruby 2.6 では、POSIX timer API が使えるなら、それを用いることで、タイマースレッドを生成しなくても良くなりました。起動時間の削減と、メモリ等のリソース消費削減に、少し効果ありそうです。

しかし、昔タイマースレッドを導入したのは私(ko1)なんですが、今回の Eric Wong さんによるこの変更、難しすぎて理解できてないんですよね...。

Fiber の実装向上

  • Native implementations (arm32, arm64, ppc64le, win32, win64, x86, amd64) of coroutines to improve performance of Fiber significantly. [Feature #14739]

NEWS エントリ的には「コルーチンをネイティブで実装した」ってありますが、コルーチンを実装するための API を CPU ごとに書いたって話になります。だいたいアセンブラで書いてあります。

技術的には、Fiber の実装には(POSIXの場合)swapcontext といった(現在では非推奨の)API を使っているのですが、こいつらが Fiber の実装にとって、若干無駄な処理をしていました。多分、一番無駄だったのは signal 関連の処理です。今回は、そういう無駄な処理を除いたコンテキスト切り替えの API を独自に作った、というものです。

Fiber 切り替えを沢山行うマイクロベンチマークでは数倍、環境によっては20倍くらい速くなったそうです。また、聞くところによると、Fiber を利用するウェブアプリで数%の性能向上があったとか。

TransientHeap による効率的なメモリ確保

  • Transient Heap (theap) is supported. [Bug #14858] [Feature #14989] theap is managed heap for short-living memory objects. For example, making small and short-living Hash object is x2 faster. With rdoc benchmark, we measured 6-7% performance improvement.

Transient Heap (theap) という新しいメモリ管理のための仕組みを導入して、短寿命のオブジェクトの生成が2倍くらい速くなりました。ただし、対応しているのは、限られたオブジェクトだけで、一番効きそうな String については未対応です。

これについては、後日改めてまとめます。

追記:まとめました。

techlife.cookpad.com

まとめ

Ruby 2.6 の NEWS ファイルの内容を駆け足でご紹介しました。ご紹介したとおり、変更いっぱいありますが、まぁ普段使ってる分にはあまり変らないと思うので、とりあえずバージョンアップしてみてはいかがでしょうか。

なお、本稿をまとめるにあたり、Ruby コミッタ各位にいろいろ「この説明で良い?」とか、「この変更ってなんでやったの?」とか、「なんでこんな仕様にしたの?」といったことを聞いて回りました。快く答えて頂きました各位に御礼申し上げます。

で、その調査の過程で、いくつかのバグを見つけたので、本稿は Ruby 2.6 のリリースに貢献しています。褒めて欲しい。

では、良い Ruby 2.6 ライフをお送りください。メリークリスマス。

(ko1)

*1:ko1: Matz が最近見つけたと言っても、私が気づいた時にはそういう仕様だったので、そういうもんだと思っていたよ...(Ruby 2.1 当時)。

*2:mame: 純粋関数型データ構造っていう、そんなことばかり考えてる本があります。

/* */ @import "/css/theme/report/report.css"; /* */ /* */ body{ background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527163350.png'); background-repeat: repeat-x; background-color:transparent; background-attachment: scroll; background-position: left top;} /* */ body{ border-top: 3px solid orange; color: #3c3c3c; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; line-height: 1.8; font-size: 16px; } a { text-decoration: underline; color: #693e1c; } a:hover { color: #80400e; text-decoration: underline; } .entry-title a{ color: rgb(176, 108, 28); cursor: auto; display: inline; font-family: 'Helvetica Neue', Helvetica, 'ヒラギノ角ゴ Pro W3', 'Hiragino Kaku Gothic Pro', Meiryo, Osaka, 'MS Pゴシック', sans-serif; font-size: 30px; font-weight: bold; height: auto; line-height: 40.5px; text-decoration: underline solid rgb(176, 108, 28); width: auto; line-height: 1.35; } .date a { color: #9b8b6c; font-size: 14px; text-decoration: none; font-weight: normal; } .urllist-title-link { font-size: 14px; } /* Recent Entries */ .recent-entries a{ color: #693e1c; } .recent-entries a:visited { color: #4d2200; text-decoration: none; } .hatena-module-recent-entries li { padding-bottom: 8px; border-bottom-width: 0px; } /*Widget*/ .hatena-module-body li { list-style-type: circle; } .hatena-module-body a{ text-decoration: none; } .hatena-module-body a:hover{ text-decoration: underline; } /* Widget name */ .hatena-module-title, .hatena-module-title a{ color: #b06c1c; margin-top: 20px; margin-bottom: 7px; } /* work frame*/ #container { width: 970px; text-align: center; margin: 0 auto; background: transparent; padding: 0 30px; } #wrapper { float: left; overflow: hidden; width: 660px; } #box2 { width: 240px; float: right; font-size: 14px; word-wrap: break-word; } /*#blog-title-inner{*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-position: left 0px;*/ /*}*/ /*.header-image-only #blog-title-inner {*/ /*background-repeat: no-repeat;*/ /*position: relative;*/ /*height: 200px;*/ /*display: none;*/ /*}*/ /*#blog-title {*/ /*margin-top: 3px;*/ /*height: 125px;*/ /*background-image: url('https://cdn-ak.f.st-hatena.com/images/fotolife/c/cookpadtech/20140527/20140527172848.png');*/ /*background-repeat: no-repeat;*/ /*background-position: left 0px;*/ /*}*/