Rails - замедляет ли рендеринг представлений использование?

У меня проблемы с производительностью на Rails 3.1.0 приложении , теперь я сделал изменения в своих запросах с помощью AR и так, но представления по-прежнему отнимают слишком много времени, я разделил представления, циклы и так далее по многим частям, которые отображаются динамически внутри представлений и внутри других частичных.

Так что это плохая практика иметь большое количество партиалов?

Должен ли я уменьшить количество партиалов, чтобы улучшить время рендеринга представлений?

Благодарность

Я не знаю существенных различий в производительности рендеринга между многими частями и одним представлением при рендеринге одного и того же контента.

Очевидно, что если вы визуализируете только некоторые партиалы в одних случаях, а другие - в других, что эффективно снижает объем рендеринга конкретного представления, вы можете получить некоторую скорость.

С другой стороны, я всегда рассматривал частичные абстрагирования, которые следует использовать как минимум в двух разных местах, чтобы оправдать их существование. Другая причина использовать партиалы - это когда вы хотите визуализировать одно и то же представление, но загружаете разные партиалы на основе имеющейся у вас бизнес-логики.

ОБНОВИТЬ:

Я не могу предложить измерения или некоторые конкретные цифры о скорости рендеринга. Если вы используете частичное представление, для его рендеринга вы вызываете метод рендеринга, поэтому существует второй вызов метода. Это, как я сказал в своем ответе, почти ничего, но может помочь немного ускорить процесс.

Однако я никогда не слышал о проекте, исправляющем проблему с производительностью путем удаления частичных компонентов. Частичные компоненты - это хороший способ предложить механизм повторного использования представлениям, и с точки зрения программистов их следует использовать для этой области. Они должны быть абстракциями для общих понятий во взглядах.

Я работал над проектом, где частичное использование было чрезмерно. Не Rails, но те же принципы MVC. Использование небольших частичек для всего, что вы можете себе представить, затрудняет их поиск, когда вы начинаете иметь десятки из них. Где бы вы искали вход для изменения? По мнению? В частичную? В какой части есть 4 части для этого представления? ...

После некоторого жесткого рефакторинга, при каждом обновлении представления мы удаляли ненужные детали. Они не исчезли полностью, но остались абстракции, которые хорошо определены для проекта. Они представляют собой хорошо понятные элементы (например, дерево для каких-либо объектов или определенный тип списка), которые повторяются в той или иной форме в нескольких представлениях. Я знаю, вижу ли я дерево, для которого есть частичное. Когда я вижу определенный тип списка, я знаю, что для этого есть частичное. Я не выслеживал их.

Читаемость кода - это самая важная вещь, которую можно сделать для базы программного кода.

Я не согласен с обоими ответами. Я скопировал и вставил код из частичного в положение, в котором он присутствует в частичном родительском представлении, и с 500 итерациями это занимает огромные 600 мс от времени, необходимого для визуализации представления. <% = render xyz%> на мой взгляд очень испорчен.

Пример, общее время визуализации:

Before:
5759.8ms
5804.2ms
5973.6ms

After:
5268.7ms
5201.6ms
5222.4ms

Diff = 5846 - 5231 = 615 ms

Edited

В итоге я удалил все _partials внутри партиала _model и опустил его до ~ 2000 мс, после чего я попытался переместить партиал _model в индекс, однако это НЕ оказало никакого влияния на время рендеринга, поэтому я предполагаю, что это с вызовами вложенного рендера. Является ли.

Не парень рельсов, но частичные представления, вероятно, не проблема сама по себе. Скорее похоже, что вы делаете немного SELECT N + 1. Посмотрите на вещи с точки зрения сервера БД, чтобы убедиться, что вы не превзошли их до предела.

Работаем над приложением Rails 4.2 прямо сейчас, где медленное действие занимает в среднем около 745 мс.

Когда я удаляю код из партиалов и помещаю его в основной шаблон, время, которое он занимает, теперь составляет в среднем менее 25 мс.

Количество звонков для рендеринга составило всего 29.

Даже если у вас нет проблемы n + 1 и все базы данных работают заранее (скажем, с рекурсивным CTE), вложенные партиалы все еще очень медленные. Хэмл и Эрб оба выглядят медленно. На Rails 5.1.4 я вижу несколько миллисекунд для каждого частичного, плюс случайные частичные, которые намного хуже (вероятно, соответствуют сборке мусора).

Я заметил, что если я переименую партиал во время выполнения одного из этих запросов, я сразу получаю сообщение о том, что файл не найден. Таким образом, по-видимому, Rails читает частичную информацию с диска, анализирует ее и оценивает для каждой итерации. Не удивительно, что это медленно!

Большая часть медлительности, наблюдаемой во вложенных партиалах, происходит только во время разработки. Переключитесь на производство для тестирования.