Rieles: ¿el uso parcial de las vistas disminuye el rendimiento?

16

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

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

¿Debo reducir la cantidad de parciales para mejorar el tiempo de representación de las vistas?

Gracias

    
pregunta Mr_Nizzle 17.07.2012 - 19:13

5 respuestas

5

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

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

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

ACTUALIZAR :

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

Sin embargo, nunca escuché que un proyecto corrigiera su problema de rendimiento al eliminar los 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 utilizarse para ese alcance. Deben ser abstractizaciones para conceptos comunes en vistas.

Trabajé en un proyecto donde los parciales se utilizaron excesivamente. No Rails, sino los mismos principios de MVC. El uso de pequeños parciales para todo lo que puedas imaginar los hace difíciles de encontrar cuando empiezas a tener docenas de ellos. ¿Dónde buscarías 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 completamente, pero lo que queda son las abstracciones que están 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é que cuando veo cierto tipo de lista 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.

    
respondido por el Patkos Csaba 17.07.2012 - 22:08
21

No estoy de acuerdo con ambas respuestas. He copiado y pegado el código de forma parcial en la posición en la que está presente en la vista principal, parcial y con 500 iteraciones, esto supone un gran recorte de tiempo de 600 ms en el procesamiento de la vista. <% = render xyz% > está en mi opinión muy roto.

Ejemplo, tiempo total para renderizar la vista:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

Editado

Terminé de desentregar todos los _partidos del _modelo parcial y lo bajé a ~ 2000ms, momento en el que intenté mover el _modelo parcial al índice, sin embargo, esto NO tuvo ningún efecto en los tiempos de renderización, así que supongo que es con llamadas a Procesamiento anidado que lo hace.

    
respondido por el AJP 03.01.2013 - 22:26
5

No es un tipo de rieles, pero las vistas parciales probablemente no sean el problema en sí. Más bien, parece que estás haciendo un poco de SELECT N + 1. Mira las cosas desde la perspectiva del servidor de DB para asegurarte de que no lo estás superando a una pulpa.

    
respondido por el Wyatt Barnett 20.07.2012 - 23:10
2

El trabajo en una aplicación Rails 4.2 en este momento es una acción lenta que, en promedio, tomaba unos 745 ms.

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

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

    
respondido por el Sammy Larbi 17.05.2017 - 21:46
1

Incluso si tiene no n + 1 problema y hace todo el trabajo de base de datos desde el principio (por ejemplo, con un CTE recursivo), los parciales anidados siguen siendo muy lentos. Haml y Erb me miran despacio. En Rails 5.1.4 Estoy viendo unos pocos milisegundos por cada parcial, más parciales ocasionales que son mucho peores (probablemente correspondientes a la recolección de basura).

Noté que si renombro el parcial mientras se ejecuta una de estas solicitudes, inmediatamente recibo un error sobre cómo no se encuentra el archivo. Así que aparentemente, Rails está leyendo el disco parcial, lo vuelve a analizar y lo evalúa para cada iteración. No es de extrañar que sea lento!

    
respondido por el Paul A Jungwirth 14.02.2018 - 06:48

Lea otras preguntas en las etiquetas