2009-11-11 3 views

Répondre

1

Oui. L'utilisation de la génération d'URL dynamique (link_to, url_for) fait que les rails recherchent la table routes et cela peut prendre du temps. Cela dit, cela est très pratique lors de la génération d'un lien qui doit envoyer une demande delete/put car il prend en charge beaucoup de choses en interne. Donc, je dirais, utilisez-les, mais utilisez-les à bon escient, seulement quand vous savez qu'ils économisent beaucoup d'entretien ou d'autres raisons d'ailleurs.

En outre, en ce qui concerne les performances, il existe several techniques pour l'améliorer. Rails caching (page, fragment, action) est un. En outre, vous voudrez peut-être jeter un oeil à this question I had asked dans le passé.

+0

Qu'est-ce que le -1? – Chirantan

+0

+1 sur l'info, bien que je ne sois pas d'accord avec ceci: "Donc je dirais, utilisez-les mais utilisez-les à bon escient, seulement quand vous savez qu'ils économisent beaucoup d'entretien ou d'autres raisons d'ailleurs." Je pense que c'est un cas clair d'optimisation prématurée. ;-) –

6

Oui, ils sont plus lents que le codage manuel des liens. Voir la présentation de Stefan Kayes au common performance problems with Rails (mais sachez que c'est à partir de 2006 donc c'est un peu daté).

Cela dit, je ne pense pas que cela soit important dans 99% des cas. La plupart des sites ne voient jamais le type de trafic où cela pourrait avoir une importance, et si vous le faites, vous pouvez généralement ajouter la mise en cache pour améliorer les performances beaucoup plus que de se débarrasser de ces aides.

Comme toujours, comparez votre situation particulière avant d'optimiser.

+1

Luke m'a battu dessus. Je vais peser avec une opinion plus forte de "ne vous inquiétez pas à ce sujet." Sur la base du ton de la question, je ne crois pas que vous êtes dans une phase de projet d'optimisation complète. Donc, non, je ne pense pas qu'il y ait de problèmes de performance * pour vous en ce moment. Profitez de la vitesse de développement pendant que vous le pouvez. La beauté de l'OSS est que, au moment où vous devez commencer à optimiser, le projet peut avoir déjà considérablement amélioré les performances d'une méthode donnée. En bref, ce ne sera certainement pas votre première préoccupation de performance, ni votre ajustement de performance de frappe plus lourd. –

+0

Merci Luke et Barry - nous ne sommes certainement pas en mode d'optimisation - plus d'une découverte du mode des meilleures pratiques. – Trey

+1

Plus précisément, j'ai parlé avec quelques collègues ici et nous sommes à peu près sûr qu'il y a eu une optimisation lourde de ces appels (optimisation du routage, vraiment) depuis que l'article a été écrit. –