Сохранить или уничтожить данные / элементы DOM?Который требует больше ресурсов?

Question

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

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

Это заставило меня задуматься о некоторых моих привычках программирования,В течение некоторого времени я очень был сосредоточен на минимизации количества запросов, которые я отправляю на сервер, что я считаю просто хорошей практикой.Но мне интересно, иногда я не захожу слишком далеко.Я очень не знаю о любых проблемах / узких местах эффективности, которые поставляются с языком JavaScript.

Пример

Недавно я создал приложение для управления изъятием для буксирующей компании.Я использовал диалоговый виджет jQuery UI и заполнил сетку данных конкретными данными заявки.На первый взгляд, это звучит очень просто ... но здесь передается МНОГО данных.

(а теперь вопрос ... drumroll пожалуйста...)

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

1) Сделать только один запросить данный билет и сохранить его постоянно в DOM.Просто показывая / скрывая модальное окно, это означает, что на один билет отправляется только один запрос.

2) Делайте запрос каждый раз, когда билет открыт, и уничтожайте его, когда он закрыт.

---

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

Я действительно просто ищу плюсы / минусы для обоих этих двух вариантов (или что-то изящное, о чем я даже не слышал = P).

Answer 1

Решение здесь зависит от специфики вашей проблемы, поскольку «правильный» ответ будет зависеть от продолжительности времени, в течение которого страница остается открытой, размера элементов DOM и задержки запроса.Вот еще несколько вещей для рассмотрения:

• Храните только самые новые n элементы в кэше.Это хорошо работает, если вы, скорее всего, будете повторно отображать элементы только в течение короткого периода времени.
• Сохраните данные для каждого элемента вместо элемента DOM и восстанавливайте DOM на каждом дисплее.
• Используйте хранилище HTML5 для хранения данных вместо DOM или хранилища переменных.Это дает дополнительное преимущество, заключающееся в том, что данные могут храниться по запросам страниц.

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

Лучший способ - начать работу с использованием самого простого метода и добавить сложность, чтобы повысить скорость только при необходимости.

Answer 2

Третий путь - хранить данные, связанные с заявкой, в JS, а также создавать и уничтожать DOM-узлы при вызове / отклонении модального окна (шаблоны jQuery здесь могут быть естественным решением).

Тем не менее, основной причиной, по которой вы избегаете сетевого трафика, является взаимодействие с пользователем (сеть медленнее, чем RAM, всегда).Но этот опыт не может быть ухудшен, если каждый раз делать запрос, если пользователь интуитивно понимает, как загружать данные.

Answer 3

Один важный фактор в количестве перерисовок / перекомпоновок, запускаемых при манипуляциях с DOM.Гораздо эффективнее создавать изменения содержимого и вставлять их за один раз, чем делать это постепенно, поскольку каждое увеличение вызывает перерисовку / перекомпоновку.

См. http://www.youtube.com/watch?v=AKZ2fj8155I, чтобы лучше это понять.

Answer 4

Я бы сказал, номер 2 будет лучшим.Потому что таким образом, если билет меняется после его открытия, это изменение появится во второй раз, когда билет будет открыт.