プロセス中に存在するすべての命令列を探し出して、必要な形に変換します。今回の場合、次のように変換されます。変わったのが見て取れると思います。使われないので、問題ないと判断しました。検討した点、苦労したところこの辺から、リリースノートに書いていない話になります。開発から10年以上たって、やっと入りました。コンパイル済みコードをキャンセルすればいい」という踏ん切りがついたためです。派手に書き換えるようにしてしまえ、と思い、このようにしてみました。命令を動的に挿入する、という選択肢もありました(これが、最も互換性に優れた方法です)。命令を増やすと命令アドレスを変更しなければならず、若干面倒です。そのため、各命令の位置は変更しない、という選択をしました(そのため、プロトタイプは一晩で実現できました)。今後、もっとアグレッシブに命令書き換えを行うためには、命令位置変更にも対応しないといけないと思っています。有効にしない場合の速度劣化を気にしなければなりませんでしたが、これからはこのオーバヘッドが気にならなくなります。向けのイベントを追加できると思っています。側をフックしたりすることができると思っています。向けの処理が不要になります。すべて不要になったタイミングで、同じようにすべての命令列を探し出して元に戻す処理を入れていました。繰り返すようなプログラムはないだろうな、という予測に基づく設計でした。上記福岡Ruby会議02で紹介した時には、このような設計をしていました。するときのオーバヘッドを軽減するための工夫も盛り込んでいます。ある程度のオーバヘッドは、やはり必要になります(具体的には、ヒープ上からすべての命令列を探し出す部分)。多く起こるため、問題になることがわかりました。無効にしても、そのままにしておくようにしました。してその後は利用しない、というシチュエーションは、あまりなさそうかな、と思い、最終的に「戻さない」とすることにしました。得られる行番号がずれる、という問題がありました。用デバッガで問題が起こる、ということがありました。リリースの直前でした。久々にリリース直前にたくさんコーディングをして(例年は、リリース直前には怖くてコードをいじれません)、なんとか問題ないところまでもっていくことができました。本件でお世話になった関係各位に感謝いたします。リリースなどでちょっと試してもらえないかと読者の皆様にお願いするところです。いうテクニックを考えて、ブロックパラメータを用いたブロック渡しを約3倍高速化することができました。何を実現したいのかあるメソッドに渡されたブロックを、ほかのメソッドに渡したい、というシチュエーションが時々あると思います。ように渡すことで、このような受け渡しを実現することができます(なお、ブロックを渡す他の(素直な)方法はありません)。するだけに比べて遅くなってしまう、という問題が生じます。オブジェクトの生成が重いためです。いう、より冗長なデータを受け取ってしまい、遅い、という問題です。ポイントは、ブロックの情報だけだったら軽い、というところです。作らなくてもよいようにすれば速くなりそうです。ある意味自明な機能なのですが、それでも名前を付けると、なんかカッコいいですよね。関係ないですけど、カッコいい手法なので興味があれば調べてみてください。必要ないのか?」ということを知る必要があることです。する必要はありません。ブロックの情報のまま、他のメソッドに渡してやればいいからです。オブジェクトを期待する(かもしれない)からです。オブジェクトを期待する(かもしれない)からです。ブロック情報のままで良さそうです。次の例はどうでしょうか。触っていないので、ブロック情報のままで良いような気がします。中身をアクセスすることができます。オブジェクトにしなければなりません。メソッドなので、任意の名前にエイリアスをつけることができます。なる可能性があるのです。そんなことは無いと思いますが。オブジェクトにする必要は無い」と言い切るのは難しそうです(このようなことを調べることを、コンパイラの用語ではエスケープ解析ということがあります)。オブジェクトを生成するようにしました。難しそうだな、どうしようかな、と考えていて実現できていませんでした。考えてみると、ブロックパラメータへのアクセスを実行時に監視すればできることに、ふと自転車を乗っているときに気づいたので、実装することができました。2.890716)ベンチマーク結果を見ると、ブロック渡しをしているケースでは、修正前と後で3倍程度性能向上していることがわかります。オブジェクトを生成せずに済みそうな気がします。変換することはできません。設定、待避を行う、という機能です。変更しても、呼び出しが終われば元通り、ということです。変換することは容易なのですが...。知らない方もいらっしゃるかと思いますが、これからも知らないでもあまり困らないのではないでしょうか。レベルのセキュリティ機能を使うことを検討してください)。ようにブロックパラメータを呼び出す速度が向上するのではないかと思います。同じくらいの速度になるんじゃないかと思います。コミッタ(パッチモンスター)の中田さん実験ではそれくらいの速度が出ているようです。その他の貢献の話さて、実はここからが本番なのです。書いてしまったので、短くまとめます。上記二つの性能向上は、良い数字が出ているので目立つのですが、実はあんまり苦労していません。だいたい数日で実現できてしまっています(その後、安定させるために、もう少し時間がかかっているんですが)。それ以外は何をしていたのでしょうか。いうものがあるのですが、結果が出るまで時間がかかる、通知がないなど不満がありました。そこで、最短で2分で結果が出る環境を整備することにしました。計算機はクラウド環境では無く、実機を利用しています。寄贈頂いたマシン、それからクックパッドで確保できたマシンを利用しています。マシン調達・運用にお世話になった/なっている皆様に深く感謝いたします。テストですと、そうでもないことがあります)。実際、いくつかの問題を発見しています(多くはテストの不備でした)。流して(普通ですね)、問題のあるコミットがあれば、すぐに気づくことができるようにしました。数十の通知が一斉に飛んでくるので、とても焦るので直さないと、という気分になります。周りの整理・改善を行いました(リファレンスマニュアル)。速くなる、というなんとも地味な結果になりました。私の発表をご参照ください。Sasadawww.slideshare.net実は、今年の多くの開発時間が、この改善につぎ込まれています。いう機能を私が作ったのが約10年前なのですが、その頃テキトーにしていたところを、全部見直して書き直す、という作業になったからです。「実行コンテキストの管理」という、バグも出やすいムズカシイ部分ですし、そもそも覚えていない。いう点でも気合いと開発時間が必要でした。うまくいかなくて、何度も最初からやり直しました。ための改善なのですが、実は狙いは将来導入を検討している新しい並行・並列のための機能を入れるための基盤作りでした。将来のデザインのために、今のうちに改善を行ったということになります。今年この点を頑張ったおかげで、来年は挑戦しやすくなったなという感触を持っています。コミッタとして活躍して頂いたことじゃないかと思います。遠藤さんによる目覚ましい成果は、だいたい私の成果と言っても過言ではないかと思います(過言です)。導入した性能向上の仕組みについて、詳しくご紹介しました。その際、どのようなことを考え、気をつけながら開発をしているかも書いてみました。つもりが、長くなってしまいました。開発の魅力を少しでもお伝えできていれば幸いです。実現のためにがんばります。インタプリタの開発が面白そうだな、と思ったら、できる限りサポートしますのでお声かけください。1月末に英語メインで開催予定ですが(申し込み締め切りは過ぎてしまいました)、2月にも日本語メインで開催しようと思いますので、よろしければ参加をご検討ください。会を、だいたい毎月どこかで開催していますので、そちらもチェック頂ければ幸いです。RHCもくもく会#4を開催予定です。寒いのでお体に気をつけて、良いお年をお迎えください。開発チームの遠藤です。f...技術部の笹田です。インタプリタの開発をしている笹田です。ファイル技術部の笹田(ko1)と遠藤(mame)です。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。