Railsパーシャルのレンダリングには実際どれくらいの時間がかかるのか？

大きなRailsビューを小さなパーシャル（部分テンプレート）に分割することをためらう方から、よくこんな質問を受けます。「パーシャルのレンダリングには実際どれくらいの時間がかかるのか？」「パーシャル呼び出しによるパフォーマンスへの影響が、コードの可読性向上のメリットを上回ってしまうのではないか？」と。

そこで今回は、シンプルなパーシャルレンダリングとインラインレンダリングを比較するベンチマークを実施しました。この結果をもとに、後半でトレードオフについて考察していきます。使用したのは、まっさらなRailsアプリケーション（config.cache_classes = true を設定済み）です。

<% require 'benchmark'
   Benchmark.bmbm do |x|
     x.report "inline" do
       10000.times do -%>
         <p>Hello!</p>
    <% end
     end
     x.report "partial" do
       10000.times do -%>
         <%= render partial: "hello" %>
    <% end
     end-%>
<% end -%>

<p>Hello!</p>

計測結果は以下の通りです（Ruby 2.1、Rails 4.0.2、2013年製15インチRetina MacBook Proで実行）：

Rehearsal -------------------------------------------
inline    0.010000   0.000000   0.010000 (  0.007045)
partial   0.970000   0.090000   1.060000 (  1.050433)
---------------------------------- total: 1.070000sec

              user     system      total        real
inline    0.010000   0.000000   0.010000 (  0.005529)
partial   0.920000   0.070000   0.990000 (  0.997491)

この結果から、ある程度スペックの高いマシンであれば、パーシャル1回あたりのレンダリング時間は平均約0.1ミリ秒であることがわかります。インラインレンダリングと比べると明らかに遅いものの、URL生成やRailsヘルパーの処理、ブラウザ側の描画時間なども考慮すれば、ユーザーが体感できるほどの差にはなりません。

スピードだけがすべてではない

仮にパーシャルのレンダリング性能がもう少し悪かったとしても、巨大なビューを分割するという判断は、おそらく同じように下したでしょう。

ソフトウェア開発には「まず動くものを作り（Make It Work）、次に正しく作り（Make It Right）、最後に速くする（Make It Fast）」という有名な格言があります。大きすぎるビューを修正しようとしている段階は、「Make It Work」から抜け出そうとしている途中であり、「Make It Fast」へ一足飛びに進むことはできません。無理に飛ばせばコードの保守性が損なわれるだけでなく、リファクタリングの機会を逃してしまうかもしれません。リファクタリングはキャッシュ導入のきっかけになり、それがさらに大きなパフォーマンス改善につながる可能性もあるのです。

計測してみなければわからない

私の計測結果を鵜呑みにする必要はありません。むしろ、ご自身で確かめることをおすすめします。Ruby標準のBenchmarkライブラリを使えば、手軽にベンチマークを実行できます。また、アプリケーション全体をプロファイリングしたい場合は、New RelicやMiniProfilerといったツールが便利です。私自身も日々の業務で、この3つを定期的に使い分けています。

なお、プロファイリングを行う際は、必ず本番モード（production環境）で実行してください。開発環境ではクラスやビューが自動的に再読み込みされるため、開発中は非常に便利ですが、そのまま計測するとパフォーマンス数値が大きく歪んでしまいます。