おもしろwebサービス開発日記

Ruby や Rails を中心に、web技術について書いています

Railsで使うビューテンプレートエンジンのベンチマーク2025

Railsでよく使われるテンプレートエンジンとしてerb(erubi)、haml、 slimがあります。パフォーマンスの観点だけをとりあげたとき、約5年前に パーフェクトRuby on Rails【増補改訂版】 を書いたときには、速い実装を選べば速度差は特にないという認識でした。それを裏付けるベンチマークはこちら↓。

当時のベンチマーク結果

2025年でも結果は変わらないかな？と思い新しくベンチマークを取ってみた結果が次のとおりです。M1 max MBPでベンチマークを取っています。

前提として、hamlのv6以降、hamlitがhamlになったのでhamlitは入れていません。あと個人的に注目しているPhlexを追加しています。

ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24]
Warming up --------------------------------------
       erubi v1.13.1    50.029k i/100ms
         slim v5.2.1    39.765k i/100ms
         haml v6.3.0    47.385k i/100ms
        phlex v2.1.1    12.770k i/100ms
Calculating -------------------------------------
       erubi v1.13.1    482.580k (± 3.0%) i/s    (2.07 μs/i) -      2.451M in   5.084563s
         slim v5.2.1    388.980k (± 4.1%) i/s    (2.57 μs/i) -      1.948M in   5.018968s
         haml v6.3.0    459.842k (± 2.6%) i/s    (2.17 μs/i) -      2.322M in   5.052679s
        phlex v2.1.1    126.474k (± 1.2%) i/s    (7.91 μs/i) -    638.500k in   5.049251s

Comparison:
       erubi v1.13.1:   482580.4 i/s
         haml v6.3.0:   459841.9 i/s - same-ish: difference falls within error
         slim v5.2.1:   388980.0 i/s - 1.24x  slower
        phlex v2.1.1:   126474.0 i/s - 3.82x  slower

erubiとhamlがslimよりも少し速い、という結果になりました。phlexは速度で勝負しているわけではないと思うのでこんなものかなあ。

今後手元で任意のバージョンでベンチマークが欲しくなったタイミングですぐにベンチマークを実行できるようにリポジトリを作っておきました。もしよければみなさんも手元で使ってみてください。

willnet/template-engine-benchmarks

ginza.rb 第88回を開催してKamalとOmakubについて学んだ

Ginza.rb 第88回 - KamalとOmakubについて学ぶぞ - connpass 第88回は、Rails8.0から標準採用されたデプロイツールKamalとDHH製ubuntuセットアップツールOmakubの2本立てでした。

Omakub

Omakubはy-yagiさん進行で The Omakub Manual をみつつワイワイしました。お仕事でRailsアプリケーションを作っている人の9割以上はmacを使っている(要出典)ので、ubuntu用セットアップツールであるOmakubの出番はないと思っている人が大半だと思いますがOmakubが採用しているツールたちは例えばbetter lsのezaだったり今どきのfuzzy finderのfzfだったりで、macでも使えるわけです。このあたりのツールを採用するきっかけとしてOmakubをウォッチするのは悪くないなと思いました。

Kamal

僕がざっくりesaにまとめた内容を見つつワイワイしました。お仕事でそれなりの規模のアプリケーションを運用するのであればやっぱりクラウドのほうが良いんじゃん？という意見がありつつ、一昔前はherokuが担っていた「One Person FrameworkとしてRailsアプリケーションを開発したあとの最初のデプロイ先」として格安のVPSを使えるようになった*1のは間口が広がって素晴らしいですねとなりました。

初学者観点だとPaaSに比べてセキュリティを確保したりホストを運用するのがちょっと難しいかもしれないというのが個人的な気になりポイントで、ホストで公開するポートを絞ったりメモリやファイルシステム容量を監視したりなどのkamalデプロイ前後のベストプラクティスがまとまってくるともっと利用者が増えてくるんじゃないかなと思いました。

会社で使う観点だと例えば37signals社がkamalを採用して年間150万ドルの予算を削減しているらしいけれど、37signals社と同様にクラウドから離れたほうがメリットがある状態(プロダクトや会社の環境)とは具体的にどういう状態なんだろうというのが気になりポイントです。おそらくインフラに強いエンジニアとアプリケーション開発に強いエンジニアが在籍しつつ、webリクエスト数がそれなりに安定していてかつクラウド独自機能が不要なふつうのWebサービスを運営しているというのが大まかな傾向だろうとは思うのですが、どこが損益分岐点なのかな。

合わせて読みたい: Rails: Kamalデプロイツールはゲームチェンジャーになるか？（翻訳）｜TechRacho by BPS株式会社

次回

次回は4月4日(金)開催予定です。春なのでHanamiについて学ぼうと思っています。興味のある人は予定を空けておいてください(\( ⁰⊖⁰)/)

*1:前から使えなかったわけではなく、初学者の人でも使いやすくなった

株式会社ウィルネットは設立8周年を迎えました

1週間前の2月21日は弊社の設立記念日でした。去年はエントリ書くのを忘れていた模様。こういうのは気づいたときに勢いで書き上げないとだめですね。

2年前のエントリ ではアウトプットを増やすぞと書いていますが、ブログの投稿数を見る感じちょっとは増えてそうです。あとはいろいろ登壇したりginza.rbを再開したりしているので、まあまあやれている方ではないでしょうか。

9年目も健康に気をつけつつ今のペースを維持したいと思います。

顧問先は継続して募集しているので、Railsアプリケーションの負債返済などに興味のある人は下記エントリを確認していただけるとうれしいです！

willnet-inc/business-details: 株式会社ウィルネットとして提供する技術顧問サービスについて

ginza.rb 第87回を開催してRuby3.4について学んだ

Ginza.rb 第87回 - Ruby3.4について学ぶぞ - connpass

第87回は、去年のクリスマスにリリースされたRuby3.4についてみんなで話し合う回でした。プロと読み解くRuby 3.4 NEWS - STORES Product Blog をみながらみんなでワイワイしました。

気になったポイント

  • 個人的には_1よりit派なのでitが使えるようになるのは嬉しいです
  • YJITが進化して、3.4にアップグレードしただけで速くなるしメモリ消費量も減る、というのはアップグレードのモチベーションが上がってよいなと思いました。
  • chilled stringを破壊したときに警告が出るのと、ブロックを使わないメソッドにブロックを渡すと警告する機能については各プロジェクトでチェックして、適宜PR投げていかないとですね…。

次回

  • 次回は2月28æ—¥(金)19:30~
  • お題はKamalとOmakubの二本立てです

東京Ruby会議12に参加した

東京Ruby会議12 に参加していました。ざっとメモ書きレベルですが感想をエントリに残しておきます。

前夜祭

すでにいろんな人が言及していますが、@makicamelさんの makicamel/erd_map: Visualize, explore, and interact with your Rails application's models and associations with ease. の発表が良かったです。voormedia/rails-erd: Generate Entity-Relationship Diagrams for Rails applicationsはいいんだけど「大きいRailsアプリケーションだと表示されるモデルの数が多くなりすぎて全体像がつかめなくなってしまう」問題があるので使いどころが難しいな、とずっと思っていて、この問題についてこんな形で解決できるんだな〜と感心しました。

あとはクラフトビールが良かったです🍻。がそのせいで飲みすぎました…＞＜

本編で気になったトーク

本編では@jhawthornのキーノートが、GitHubのRuby/Railsに対する取り組み方を幅広くまとめていて印象深かったです。一番なるほどなあとなったのは、複数DBのプライマリ/セカンダリを自動で切り替えるときのロジックで「更新系のクエリを発行したらその後の参照系は一定時間プライマリを参照する」の「一定時間」の部分をgithub/freno: freno: cooperative, highly available throttler serviceを利用して動的に決定しているという話。デフォルトは2s固定なんだけど、固定値じゃないほうがいいよなとずっと思っていたところだったので参考となる情報を知れてよかったです。

ref: ActiveRecord::Middleware::DatabaseSelector

Regional.rb and the Tokyo Metropolis

Regional.rb and the Tokyo Metropolisという名前で、東京近郊の地域Rubyコミュニティの代表が集まってトークする会に出演しました。ぼくもコミュニティの一員として賑やかしに貢献できたのではないかと思います。ginza.rbもそうですがコロナ禍で中断していたコミュニティが多くあったので、その間にRubyを始めた人は地域Rubyコミュニティについてよく知らない状態なはず。そういった人たちとコミュニティの距離を近づけるのに一役買った良い試みだったのではないでしょうか。これから新しいコミュニティが始まりそうな機運も感じられました(機運だけじゃなくてすでに活動始まってるコミュニティもありますね)。

ginza.rbは2013年発なので(コロナ禍で休止していた期間も含めると)12年目に突入しています。始めた当初はこんなに長寿コミュニティになるとは思ってもみませんでしたね…。これからも無理せずぼちぼちとやっていきますので機会があったら遊びに来てください。

技術顧問として提供するサービス内容をまとめた

僕がRails技術顧問という形態で働き始めたのは2016年の1月のことでした。すると今時点でおよそ9年ほど技術顧問をしていることになります。だいぶ長くやっていますね…。2年が経過した時点でブログエントリとしてどんなことをしたかまとめましたが、そこからさらに7年近く経過しておりブログエントリの鮮度はだいぶ落ちています。これから弊社に依頼する会社にとって、7年の間にやったことを盛り込んでおいたほうが良いだろうと考えて内容を書き直しました。成果物はこちらです。

willnet-inc/business-details: 株式会社ウィルネットとして提供する技術顧問サービスについて

あとで更新できるようにGitHub上で文章を管理しています*1。

やっていることの大まかな方向性は上記ブログエントリを書いたときと変わっていないのですが、具体的な事例が増えたことで解像度がさらに高くなったのではないかと感じています。

週1程度の顧問先を募集しています

週1日程度の空きがあるので、もしRailsを利用していて外部の知見がほしいぞ、という会社さんがいましたら何らかの手段*2でご連絡ください。

*1:コーポレートサイトでもいいんだけどGitHubの方が手っ取り早かったので…。将来的にはコーポレートサイトの方に移行するかもしれません

*2:コーポレートサイトのお問い合わせフォームなど

ginza.rb 第86回を開催してRails8.0について学んだ

Ginza.rb 第86回 - Rails8.0について学ぶぞ - connpass

第86回は、11月にリリースされたRails8.0についてみんなで話し合う回でした。y-yagiさんが作ってくれた資料を使ってワイワイしました。

About Rails 8.0 - Slidev

気になったポイント

メジャーフィーチャー扱いだと思われるGetting SQLite ready for productionについては、for productionとはいえ我々(仕事でRailsアプリケーションを書いている人)がSQLiteを本番で使う機会はなかなかなさそうですね、という話をしました。ここで言う"production"はenterpriseを含まず、個人開発とかCampfireなどの社内用の簡単なアプリケーションなんじゃないですかね。

Rails6あたりの大企業向けの機能追加から、DHH主導によるThe One Person Framework化が目立ったのがRails8.0である、という話もしました。これまで以上に「個人開発者がいろんな複雑さを避けつつサービスを公開するところまで行ける」を意識している印象。「いろんな複雑さ」というのは例えば

  • jsã‚„cssのコンパイル
  • redisのセットアップ
  • Paasやクラウドのお作法を学ぶこと
  • MySQLもしくはPostgreSQLなどのセットアップ

のようなものたち。とにかく最初のハードルを下げるのが肝要で、サービスが成長したら売上も上がるはずなのでそのタイミングで構成要素を変更していけばいいよね、という方針なんじゃないかな…？

しかし一方で会社でRailsアプリケーションを作っている我々はThe One Personではないのでその点では恩恵を得づらい部分もありそう。まあそれはそうですね…。

マイナーフィーチャまとめ

y-yagiさんの資料と8割くらい被ってるけど、僕もざっくりマイナーフィーチャーについてgistにまとめておいたのでリンクだけ置いておきます(ginza.rb中では話す時間がなかった)。

Rails8.0のマイナーフィーチャーで気になったところ

次回

1月24日(金)に開催予定です。内容はRuby3.4。ご都合の合う方良ければご参加ください。