Rails - L'utilisation de partiels ralentit-elle le rendu des vues?

J'ai des problèmes de performances sur une 3.1.0application Rails , maintenant j'ai fait des changements de dôme sur mes requêtes avec AR et ainsi, mais les vues prennent encore trop de temps à rendre, j'ai divisé les vues, les boucles et ainsi, sur de nombreux partiels qui sont rendus dynamiquement à l'intérieur des vues et à l'intérieur d'autres partiels.

C'est donc une mauvaise pratique d'avoir un grand nombre de partiels?

Dois-je réduire le nombre de partiels pour améliorer le temps de rendu des vues?

Merci

Je ne connais aucune différence de performance de rendu significative entre de nombreux partiels et une seule vue lorsque vous restituez le même contenu.

Évidemment, si vous ne rendez que certains partiels dans certains cas et d'autres dans d'autres cas, ce qui réduit efficacement le volume de rendu d'une vue spécifique, vous pouvez gagner en vitesse.

D'un autre côté, j'ai toujours considéré des résumés partiels qui devraient être utilisés au moins à partir de 2 endroits différents pour justifier leur existence. L'autre raison d'utiliser des partiels est lorsque vous souhaitez rendre la même vue mais charger différents partiels en fonction de votre logique métier.

MISE À JOUR:

Je ne peux pas proposer de mesure ou de chiffres concrets sur la vitesse de rendu. Si vous utilisez un partiel dans une vue, pour le rendre, vous appelez la méthode de rendu, il y a donc un deuxième appel de méthode. Comme je l'ai dit dans ma réponse, cela ne sert à rien, mais peut aider à accélérer un peu les choses.

Cependant, je n'ai jamais entendu parler d'un projet corrigeant son problème de performances en supprimant les partiels. Les partiels sont un bon moyen d'offrir un mécanisme de réutilisation aux vues et, du point de vue des programmeurs, ils doivent être utilisés pour cette étendue. Ils doivent être des résumés pour des concepts communs dans les vues.

J'ai travaillé sur un projet où les partiels étaient excessivement utilisés. Pas Rails, mais les mêmes principes MVC. L'utilisation de petits partiels pour tout ce que vous pouvez imaginer les rend difficiles à trouver lorsque vous commencez à en avoir des dizaines. Où rechercheriez-vous une entrée à modifier? Dans la vue? Dans un partiel? Dans quel partiel, il y a 4 partiels pour cette vue? ...

Après quelques refactorisations dures, à chaque mise à jour d'une vue, nous supprimions les partiels inutiles. Ils n'ont pas complètement disparu, mais il reste des résumés bien définis pour le projet. Ils représentent des éléments bien compris (comme un arbre pour une sorte d'objets, ou un type de liste spécifique) qui se répètent sous une forme ou une autre sur plusieurs vues. Je sais que si je vois un arbre, il y en a un partiel. Je sais que lorsque je vois un certain type de liste, il y en a une partielle. Je ne dois pas les traquer.

La lisibilité du code est la chose la plus importante que l'on puisse faire pour une base de code logiciel.

Je suis en désaccord avec les deux réponses. J'ai copié et collé le code d'un partiel dans la position qu'il est présent dans la vue parent partielle et avec 500 itérations, cela prend un énorme 600 ms sur le temps nécessaire pour rendre la vue. <% = render xyz%> est à mon avis très cassé.

Exemple, temps total pour rendre la vue:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

Édité

J'ai fini par désessayer tous les _partials dans le partiel _model et je suis descendu à ~ 2000 ms, moment auquel j'ai essayé de déplacer le _model partiel dans l'index, mais cela n'a eu aucun effet sur les temps de rendu, donc je suppose que c'est avec des appels au rendu imbriqué que le fait.

Pas un gars de rails, mais les vues partielles ne sont probablement pas le problème en soi. Il semble plutôt que vous fassiez un peu de SELECT N + 1. Regardez les choses du point de vue du serveur DB pour vous assurer que vous ne les battez pas en bouillie.

Travailler sur une application Rails 4.2 en ce moment où une action lente qui prenait environ 745 ms en moyenne.

Lorsque je supprime le code des partiels et le place dans le modèle principal, le temps qu'il faut est désormais en moyenne inférieur à 25 ms.

Le nombre d'appels pour rendre les partiels n'était que de 29.

Même si vous n'avez pas de problème n + 1 et que vous faites tout le travail de base de données à l'avance (disons avec un CTE récursif), les partiels imbriqués sont toujours très lents. Haml et Erb me semblent tous les deux lents. Sur Rails 5.1.4, je vois quelques millisecondes pour chaque partiel, plus des partiels occasionnels qui sont bien pires (correspondant probablement à la récupération de place).

J'ai remarqué que si je renomme le partiel pendant qu'une de ces demandes est en cours d'exécution, j'obtiens immédiatement une erreur sur la façon dont le fichier n'est pas trouvé. Donc apparemment, Rails lit le disque partiel, le réanalyse et l'évalue pour chaque itération. Pas étonnant que ce soit lent!

Une grande partie de la lenteur observée dans les partiels imbriqués ne se produit que pendant le développement. Passez en production pour tester.