回答:
同じコンテンツをレンダリングする場合、多くのパーシャルと1つのビューの間にレンダリングパフォーマンスの大きな違いがないことを知っています。
明らかに、特定のビューのレンダリングボリュームを効果的に削減するなど、特定のビューの一部のみをレンダリングし、他のケースを他のケースでレンダリングすると、速度が向上する場合があります。
一方で、私はパーシャルの抽象化を常に考慮しました。パーシャルの抽象化は、少なくとも2つの異なる場所から使用して、それらの存在を正当化する必要があります。パーシャルを使用するもう1つの理由は、同じビューをレンダリングしたいが、ビジネスロジックに基づいて異なるパーシャルをロードする場合です。
更新：
レンダリング速度に関する測定値や具体的な数値を提供することはできません。ビューでパーシャルを使用する場合、レンダリングするためにrenderメソッドを呼び出すため、2番目のメソッド呼び出しがあります。これは私の答えで言ったように、ほとんど何もありませんが、物事を少しスピードアップするのに役立つかもしれません。
しかし、パーシャルを削除することでパフォーマンスの問題を修正するプロジェクトについて聞いたことがありません。パーシャルは、ビューに再利用メカニズムを提供する良い方法であり、プログラマーのビューからは、そのスコープで使用する必要があります。ビューの一般的な概念を抽象化する必要があります。
私はパーシャルが過度に使用されるプロジェクトに取り組みました。Railsではなく、同じMVCの原則。想像できるすべてのものに小さなパーシャルを使用すると、数十個のパーシャルを見つけ始めたときにそれらを見つけるのが難しくなります。変更する入力をどこで探しますか？ビューで？部分的に？このビューには、どのパーシャルに4つのパーシャルがありますか？...
いくつかのハードリファクタリングの後、ビューを更新するたびに、不要なパーシャルを削除しました。完全に消えたわけではありませんが、残っているのはプロジェクトのために明確に定義された抽象化です。これらは、いくつかのビューでフォームなどで繰り返される、よく理解されている要素（何らかのオブジェクトのツリー、または特定のリストタイプなど）を表します。私はそのために部分的である木を見れば知っています。特定の種類のリストを見ると、その部分的なものがあることがわかります。私はそれらを追い詰める必要はありません。
コードの読みやすさは、ソフトウェアコードベースでできる最も重要なことです。
Code readability、それはすべてのことです。
私は両方の答えに同意しません。パーシャルからコードをコピーして、親ビューのパーシャルに存在する位置に貼り付けましたが、500回の繰り返しで、ビューのレンダリングにかかる時間が600ミリ秒かかりました。<％= render xyz％>は私の意見では非常に壊れています。
例、ビューをレンダリングする合計時間：
Before:
5759.8ms
5804.2ms
5973.6ms
After:
5268.7ms
5201.6ms
5222.4ms
Diff = 5846 - 5231 = 615 ms
編集済み
最終的に_modelパーシャル内のすべての_partialsをunDRYし、〜2000msに下げました。その時点で_modelパーシャルをインデックスに移動しようとしましたが、これはレンダリング時間に影響を与えなかったため、それをします。
Railsの男ではありませんが、部分ビューは問題ではない可能性があります。むしろ、SELECT N + 1を少し実行しているように聞こえます。DBサーバーの観点から物事を見て、あなたがそれをパルプに打ち負かしていないことを確認してください。
n + 1に問題がなく、すべてのデータベースを事前に処理する場合（再帰CTEなど）でも、ネストされたパーシャルは非常に低速です。HamlとErbはどちらも私には遅いようです。Rails 5.1.4では、各パーシャルに数ミリ秒が表示されますが、さらに悪化することがあります（おそらくガベージコレクションに対応）。
これらのリクエストのいずれかが実行されている間にパーシャルの名前を変更すると、ファイルが見つからないというエラーがすぐに表示されることに気付きました。どうやらRailsはディスクからパーシャルを読み取り、再解析し、各反復で評価しています。遅いのも不思議ではありません！