Rails: ¿el uso de parciales retrasa la representación de vistas?

Tengo problemas de rendimiento en una 3.1.0aplicación de Rails , ahora he realizado cambios de domo en mis consultas con AR y, por lo tanto, las vistas aún requieren demasiado tiempo para procesarse, he dividido las vistas, los bucles, etc., en muchos parciales que se representan dinámicamente dentro de las vistas y dentro de otros parciales.

¿Entonces es una mala práctica tener una gran cantidad de parciales?

¿Debería reducir el número de parciales para mejorar el tiempo de representación de las vistas?

Gracias

No conozco ninguna diferencia de rendimiento de representación significativa entre muchos parciales y una sola vista cuando representa el mismo contenido.

Obviamente, si renderiza solo algunos parciales en algunos casos y otros en otros casos, reduciendo efectivamente el volumen de representación de una vista específica, entonces puede ganar algo de velocidad.

Por otro lado, siempre consideré las abstracciones parciales que deberían usarse al menos desde 2 lugares diferentes para justificar su existencia. La otra razón para usar parciales es cuando desea renderizar la misma vista pero cargar parciales diferentes según la lógica de negocios que tenga.

ACTUALIZAR:

No puedo ofrecer una medida o algunos números concretos sobre la velocidad de renderizado. Si usa un parcial en una vista, para representarlo llama al método de representación, por lo que hay una segunda llamada al método. Esto, como dije en mi respuesta, no es casi nada, pero puede ayudar a acelerar las cosas un poco.

Sin embargo, nunca escuché de un proyecto que solucione su problema de rendimiento eliminando parciales. Los parciales son una buena manera de ofrecer un mecanismo de reutilización a las vistas y, desde la vista de los programadores, deberían usarse para ese alcance. Deben ser abstractizaciones para conceptos comunes en vistas.

Trabajé en un proyecto donde los parciales se usaban en exceso. No Rails, sino los mismos principios MVC. Usar pequeños parciales para todo lo que puedas imaginar los hace difíciles de encontrar cuando comienzas a tener docenas de ellos. ¿Dónde buscaría una entrada para modificar? En la vista? En un parcial? ¿En qué parcial, hay 4 parciales para esta vista? ...

Después de algunas refactorizaciones difíciles, con cada actualización de una vista, eliminamos los parciales innecesarios. No desaparecieron por completo, pero lo que queda son abstracciones bien definidas para el proyecto. Representan elementos bien entendidos (como un árbol para algún tipo de objetos o un tipo de lista específico) que se repiten de una forma u otra en varias vistas. Sé que si veo un árbol hay un parcial para eso. Sé cuando veo cierto tipo de lista que hay un parcial para eso. No los he cazado.

La legibilidad del código es lo más importante que se puede hacer para una base de código de software.

No estoy de acuerdo con ambas respuestas. He copiado y pegado el código de forma parcial en la posición que está presente en la vista primaria parcial y con 500 iteraciones, esto toma unos 600 ms del tiempo que se tarda en representar la vista. <% = render xyz%> en mi opinión está muy roto.

Ejemplo, tiempo total para representar la vista:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

Editado

Terminé desempolvando todos los _partiales dentro del _modelo parcial y lo bajé a ~ 2000 ms, en cuyo punto intenté mover el _modelo parcial al índice, sin embargo, esto NO tuvo ningún efecto en los tiempos de renderizado, así que supongo que es con llamadas a renderizado anidado que lo hace.

No es un tipo de rieles, pero las vistas parciales probablemente no sean el problema per se. Más bien, parece que estás haciendo un poco de SELECT N + 1. Mire las cosas desde la perspectiva del servidor de base de datos para asegurarse de que no lo está superando.

Trabajando en una aplicación Rails 4.2 en este momento, una acción lenta que tomaba alrededor de 745 ms en promedio.

Cuando elimino el código de los parciales y lo coloco en la plantilla principal, el tiempo que toma ahora es en promedio menos de 25 ms.

El número de llamadas para representar los parciales fue de solo 29.

Incluso si no tiene un problema n + 1 y hace que toda la base de datos funcione por adelantado (digamos con un CTE recursivo), los parciales anidados siguen siendo muy lentos. Haml y Erb me parecen lentos. On Rails 5.1.4 Estoy viendo unos pocos milisegundos por cada parcial, además de parciales ocasionales que son mucho peores (probablemente correspondientes a la recolección de basura).

Noté que si cambio el nombre del parcial mientras se ejecuta una de estas solicitudes, inmediatamente recibo un error sobre cómo no se encuentra el archivo. Entonces, aparentemente Rails está leyendo el disco parcial, volviéndolo a analizar y evaluándolo para cada iteración. ¡No es de extrañar que sea lento!

Mucha de la lentitud que se ve en parciales anidados ocurre solo durante el desarrollo. Cambie a producción para probar.