いかにしてRubyを高速化するか？ コミッター・卜部昌平が挑んだ「Deoptimization Ruby」の軌跡 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
Ruby1.8.5、1.8.6、1.8.7のリリースマネージャを務め、現在は株式会社マネーフォワードでフルタイムのRubyコミッター職として働く卜部昌平（うらべ・しょうへい／@shyouhei）さんは、deoptimizationと呼ばれるアプローチを用いてRubyの高速化に取り組んでいます。 本稿ではその足跡から、いかなる思想のもとでデザインや実装を行っているかを、卜部さん本人が解説します。 Deoptimizationの着想に至るまで デザインとは、やらないことを決めること 「最適化が間違っていたら、戻す」をどう実装するか？ インストラクションを消し、跡地をnopで埋める 「メソッド呼び出しが省略可能であること」を判定するために 省略可能な呼び出され方を増やす 大き過ぎる問題ではなく、実現できる規模の問題に取り組む Deoptimizationの着想に至るまで 言語を高速化するときに、
全てのRubyエンジニアはだいたい糞である
汎用系のエンジニアからRubyのエンジニアとして転職して1年。 コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。 その特徴はだいたいこの3つだ。 1.テストを甘く見ているやれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。 そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。 テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。 そもそもテストケース表を若いうちに書く習慣が無いからだ。 ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。 2.パフォーマンスを考えないRubyエンジニアはパフォーマンスを考えない。 どのメソッドがどれくらいの負荷なのか意識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
