Ruby 3.3がリリースされた。YJITには非常に多くの改善が含まれたリリースだったが、 NEWS解説記事やリリースパーティーでは 2点しか触れられなかったので、この記事ではRuby 3.3でYJITがどう改善されたかについて解説する。 YJITは既に実用段階 YJITはRuby 3.1で導入されたが、Ruby 3.2の時点でexperimentalのマークが外れ、実用段階となった。 Ruby 3.2では、以下のような企業で性能改善が報告された。 DeNA: 40% 高速化 GMOペバボ: 18% 高速化 STORES: 6.5-7.5% 高速化 Timee: 10% 高速化 メドピア: 2.8% 高速化 BOOK☆WALKER: 20-30% 高速化 Discourse: 15.8-19.6% 高速化 Lobsters: 26% 高速化 CompanyCam: 20-40% 高速化 弊

僕はRubyで開発をする時は毎回Pryを使うくらいの熱狂的Pryユーザーだったのだが、PryはGemfileに書いてないと binding.pry できなくて不便。任意のgemをdefault gem化するgem default コマンドも作ったのだが、これをやるのすら面倒だと思っていた。 ある日、nobuさんがRubyに binding.irb という機能をいれた。Pryがdefault gemになるのを待つよりPryで僕が使う機能をIRBに全部移植してしまった方が早いのではないかと思い、4年前からPryの機能の移植活動を始め、今日僕がよく使う機能を全て移植し終えた。 その記念に、この記事ではIRBのPry互換の機能を紹介する。昔 今更聞けないpryの使い方と便利プラグイン集 という記事を書いたんだけど、この中で僕が毎日のように使うコマンドは全てIRBに移植したので、それを紹介する本稿を

サンフランシスコベイエリアでのITエンジニアの給料は東京より高いが、税金や物価も高いと言われている *1 。ではどちらに住む方がより多くの金が手元に残るのだろうか。 僕がベイエリアに移住してからちょうど1年が経ったので、僕が東京とベイエリアそれぞれにいた頃の出費やタイトルでどのくらい家の収支に差が出るのかということをまとめてみる。なお、この記事を書いている時点で 105.60 円/ドル なので、ドル円の変換をする際はこのレートを用いる *2 。 収入 基本給 ベイエリア 東京 $153,600 913万円 GitLabは同社の世界各地での待遇計算基準を 公開 しており、地域間の差異を公平に計算するには割とよくできたベンチマークなのでここの年収をそのまま使う。計算に使われる location_factors.yml では、日本の給与はサンフランシスコの 56.3% になっている。 Calcu

先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回

今年GitHubがGraphQL APIを正式公開したあたりから、GraphQLが去年とかに比べちょっと流行り始めたように感じる。idobataがGraphQL APIを公開したり、Kibelaも公開APIをGraphQLで作ることを宣言している。 利用者側からすると使えるインターフェースの中から必要なものを調べて使うだけなのであまり考えることはないのだが、自分がAPIを提供する立場になると話は変わってくる。REST APIとGraphQL APIはどちらかがもう一方のスーパーセットという風にはなっておらず、どちらかを選択すると何かを捨てることになるので、要件に応じてどちらを選ぶのが総合的に幸せなのか考える必要がある。 以前趣味でGitHub連携のあるサービスを作っており、それを最近GraphQL API v4を使うように移行し、そこでついでにそのサービスのGraphQL APIを書いてみ

LLRBというRuby向けのメソッドJITコンパイラを書いている github.com RubyKaigi 2015の最後のキーノートで@evanphxが「LLVMでCRubyのコードをインライン化するメソッドJITを実装したら速いんじゃね」みたいな発表をしていたのを覚えているだろうか。 LLRBというのはまさにそれを実装しているプロジェクトであり、少なくとも現時点で「LLVMでCRubyのコードをインライン化するメソッドJIT」と言える状態まで実装でき、ものによっては効果が出る状態になったので公開した。 なんで書いてるの 言語を自分で実装するとその言語に関する理解が大分深まる、というのをHamlの実装とかCコンパイラとかで体験していて、僕が一番好きな言語はRubyなのでRubyでもそれをやっておきたい、というのがあった。また、Rubyは遅いと言われがちだが、どこに改善可能な点が眠っている

3月から Treasure Data で働いています。入社初日からタスクをアサインされ、RailsでAPIの開発をやりました。 なぜ Treasure Data に転職したのか 前職もやりたいことができて優秀な同僚に囲まれ文句ない環境だったのですが、アルバイト入社から数えるともう3年半が経っていたし、入社前にイメージしていたような仕事も大体経験できていました。 そのままいても良かったのですが、ある程度の間隔で新しいことに挑戦しないと成長は止まってしまうと思っているので職場ごと変えることも考え始め、以下のような観点から Treasure Data に転職することに決めました。 エンジニアがユーザーになる仕事をしてみたい 僕は開発者が使うツールを作るのが好きで、技術を売っている会社の方がそういうものを作る機会が増えそう 正直あまりエンジニアリング以外に興味がないので、一般の人を対象にしたサービ

高速なHTMLエスケープをするライブラリを作った ある日HTMLエスケープを速くしたくなって、hescapeというライブラリを作った。 github.com とにかく速いHTMLエスケープがしたい Railsアプリのビューのレンダリングにおいて、CGI.escapeHTMLを高速化*1することでRailsのデフォルトのテンプレートエンジンが大きく高速化されたり*2、GitHubでもHTMLエスケープが全体のパフォーマンスに影響が大きかった事例もある*3など、常に自動でHTMLエスケープが行なわれるRailsの環境ではHTMLエスケープの速度が割と大きな意味を持っている。 従って、Hamlitの最速性を維持するためにHTMLエスケープのパフォーマンスを極めておきたかった。 vmg/houdini を倒したい 前述したGitHubの人が既にhoudiniというかなり速いエスケープライブラリを作

itamae-goを作り直してitamae-mrubyを作った 先週Goからmrubyを使ってRubyなしでItamaeレシピを実行できる「itamae-go」を作ったんだけど、全く同じコンセプトの、RubyなしでItamaeレシピを実行できる「itamae-mruby」を作った。 github.com itamae-goの問題点 mrubyは組み込み言語だしこれは本来想定された使い方であり、go-mrubyの実用的な例として普通に作ってよかったと思っているけど、ことItamaeを実装することに関しては以下のような問題があった。 レシピを読む部分以外をGoで実装していたので、specinfraのコードの移植に手間がかかる 主にstandaloneなバイナリを吐く目的にGoが使われているが、mruby-cliでもできるのでGoを使っているメリットがそれほどなく、2つの言語をブリッジするコード

Slimより高速なHaml実装「Hamlit」 RubyでHTMLを生成するのにERB以外でよく使われるテンプレート言語にHamlやSlimがあります。haml *1 をやめて高速なslimに移行する人が多かったのですが、私はHamlのシンタックスの方が好きなので、slimが用意したベンチマークでslimより高速なHaml実装「Hamlit」を3月にリリースしました。 *2 これはslimが提供しているベンチマークでHTML escapeを有効にし *3、FamlとHamlitを追加したベンチマークの結果です。なおHamlitは完全にHaml互換の仕様ではなく、この非互換が有利に働いています。 互換性と性能が大幅に向上したHamlit v2.0 Hamlitの互換性の問題 Hamlitは最初のv0.1の時点で上記のようなベンチでSlimより高速ではあったのですが、以下のような欠陥がありまし

byebugとpry-byebugのbundle updateをしましょう byebugはRails標準でインストールされるRuby 2.1, 2.2向けのデバッガで、pry-byebugはpry *1 にデバッガの機能を追加するpryのプラグインです。 一昨日から今日にかけて、以下のパフォーマンス改善を含む byebug v8.0.0 と pry-byebug v3.3.0 がリリースされました。 github.com github.com byebugとpry-byebugには、一度byebugやbinding.pryを叩くとそれ以降ずっとアプリケーションの挙動が10倍遅くなるという問題がありました。 これが上記の変更により改善されたので、 Railsアプリやgemのデバッグにbyebugやpry-byebugを利用している方はそれらのbundle updateをおすすめします。 bi

3月末に、Hamlit v0.1.0を作りSlimやErubisより高速なHaml実装「Hamlit」をリリースしましたという記事を書いた。 haml-specを通しているのでHamlと高い互換性と持っていてかつ速いという宣言をしたものの、実際にリリースしてみると随所からバグ報告が上がり、 hamlを置き換えただけでは動かない haml-specは互換性の保証にはならず、速いのは互換性が低いからでは？ このベンチはHamlitがhtmlエスケープをしていないから速いだけでは？ のような声が随所から上がった。 今日、attributeのescapeに対応し、 全てのissueを潰した上で、Slimより速いベンチを出すことに成功した ので、v0.1.0での問題点やそこからの変更点などについて書きたいと思う。 v0.1.0での問題点 haml-specガバガバ問題 @k0kubun それな— 獣

slim-template/slimのcompiled benchでオリジナルのhamlに比べ8倍高速に動作するhaml実装をリリースしました。 github.com なぜ高速なHaml実装を作ったのか 個人的にhamlのシンタックスのほうが好きなので、「hamlは遅いからslimを使う」みたいな人を減らしたかったから。以前slimの普及に貢献したんだけど、気が変わったのでhamlを応援することにした。 実は他にも既にeagletmt/famlという高速なHaml実装が存在していたんだけどベンチを走らせたらslimより遅かったので、slimを打倒するべく再実装した。 どのくらいHamlより速いのか 自分の実装に都合のいいベンチマークを作るのは簡単なので、公平性を期すためにslim-template/slimのcompiled benchと同じものを使い、誰でも同じ環境が使えるtravisで

RubyKaigi 2014行った。良い発表がいろいろ聞けたんだけど、最近ISUCONに向けてwebアプリのチューニングに興味があったので特にfinal keynoteが興味深かった。 その中で紹介されていたtmm1/rblineprofが行ごとの実行時間を表示してくれるのでとても便利そうだったんだけど、GitHubではpeek/peek-rblineprofというRails用のプラグインでrblineprofを活用しているので、ISUCONでおそらく使用されるであろうsinatraでどうやって使うか考えていた。 kainosnoema/rack-lineprofというgemがその用途に便利そうだったので紹介したい。 使い方 rack-lineprofはRack middlewareで、まず以下のようにuseする必要がある。 require 'rack-lineprof' class My