Tech Racho エンジニアの「？」を「！」に。
  1. TOP
  2. Ruby / Rails関連
  3. キーワードで振り返るRubyKaigi 2019@博多（#4）最適化、パターンマッチング、mruby、ブランチメンテナンスほか
  • Ruby / Rails関連

キーワードで振り返るRubyKaigi 2019@博多（#4）最適化、パターンマッチング、mruby、ブランチメンテナンスほか

RubyKaigi 2019の発表資料がだいぶ揃ったようです。ありがとうございます！


rubykaigi.orgより

誤りや追加情報などがありましたら@hachi8833までお知らせください。

「最適化」

やはり最適化が最も多いですね。

残念ながら現地で見られませんでしたが、ko1さんの発表は「Cで書かれているRubyの組み込みメソッドのうち、単にCのライブラリを呼んでいる程度のものはRubyで書けるならRubyで書こう」という趣旨でした。RubyのFFI（foreign function interface）を用いて、RubyコードからCのコードを呼び出す形で組み込みメソッドを書き、それに応じてVMにinvokecfuncwparamなどのインストラクションを追加したことで、Cネイティブのメソッドより高速にできたというものです。上述のご本人のブログが最もわかりやすいと思います。

当日見られなかったセッションのうち、@shyouheiさんの「The send-pop optimisation」のスライドを見直しました。頻繁に実行されるpopの呼び出し回数を減らすという、VMの内部に切り込む最適化でした。

参考: ffi/ffi: Ruby FFI

オーラスのJeremy Evanさんのキーノートは、そのまま業務に使ったらやばそうなRubyコード最適化を怒涛の勢いで紹介していました。morimorihogeさんの所感は「すべてを理解しなくてもいいけど、パフォーマンスチューニングに慣れていない人が『こういう書き方は遅い臭いがする』という感覚を養うのにいいと思う」でした。

「mruby」「mruby/c」

気がつけばmruby関連のセッションは見られずでした😢。しかもDay 2夜にmrubyのワークショップ（先着50名様）↓が開催されていたことも今になって気づきました。

遅ればせながら、最近ゆっくりゆっくりmrubyの構成を追っています。mrubyのコンパイラがmrbgemsの形式になっていてなぜ？と思っているレベルです。mrubyのparser.yは7000行とRubyよりは小さいものの、コードがぎっしりでビビりました。

「ブランチメンテナンス」

安定版ブランチメンテナーの@nagachikaさんが、バグフィックスをバックポートするかどうかをジャッジすることの難しさについて発表しました。原則は「バグフィックスはバックポートする」「パフォーマンス改善や新機能や仕様変更はバックポートしない」なのですが、きれいにトリアージできるとは限らずに悩んだり、ときにはバックポートすべきでないものをバックポートしてしまったりというさまざまな経験談に、ブランチメンテナーにのしかかるプレッシャーを実感しました。「個人的にはエッジを効かせたいけど、安定したRubyを届けたい」という言葉が思い出されます。

  • メモリ探索の修正はメモリ違反が発生しやすい
  • Refinementの細かい仕様が定まっていない部分が改修の影響を受けることも
  • シンタックスエラーはモンキーパッチでは修正できない（当然ですが）
  • parser.yは魔境
  • ずっと前からあるシンタックスエラーは、無理に直すより優先順位を下げて既知のバグにする方がよいことも
  • テストですべてのエラーをカバーするのは難しい

「モナド」「パターンマッチング」

少々無理やりですが、@joker1007さんのモナドパターン話と、@joker1007さんを含め多くの人が期待を寄せているパターンマッチングをここに置きました。モナドむずい…

パターンマッチングのスライドを見返すと、特にJSONのようなネストしたパターンをそのままinで扱えるあたりがスゴいと思いました。今までなかったのが不思議な機能ですね。

参考: Ruby 2.7 — Pattern Matching — First Impressions – Brandon Weaver – Medium
参考: Ruby 2.7 — Pattern Matching — Destructuring on Point

「デバッグ」「監視」「クリーンアップ」「テスト」

「Cleaning up a huge ruby application」を見たmorimorihogeさんの所感は「Ruby 2.4から入ったコード実行されたどうかを調べるIseqLoggerを使ったり、2.6のcoverage機能を使って『コードはあるけど実際には実行されていないコード』を抽出・削除していく話。完全自動化まではいかないけれども、膨大なコードからアタリを付けて消していくのに十分な情報が得られているように見えた」でした。

「Bundler」

「The future of the Bundled Bundler with RubyGems」では、Bundlerの現状と、将来のBundler 4で入るbreaking changesなどが紹介されていました。

「API」

「キーワードで振り返るRubyKaigi 2019」はこれにて一区切りいたします🙇。

関連記事

キーワードで振り返るRubyKaigi 2019@博多（#1）

キーワードで振り返るRubyKaigi 2019@博多（#2）Rails、JIT、コントリビューション

キーワードで振り返るRubyKaigi 2019@博多（#3）サーバーレス、スレッド、データサイエンス、Apple IIほか


この記事を書いた人

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事一覧へ
タグ

CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。
CONTACT FORM