Сколько HTML-элементов могут "современные" браузеры "обрабатывать" сразу?

"современный", поскольку это определение может меняться со временем (и, в частности, я имею в виду настольные браузеры)

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

Этот вопрос напомнил о конкретной проблеме, которую я пытаюсь решить с помощью больших наборов данных.

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

Так, например, над websocket я получаю событие push, которое сообщает мне, что набор данных имеет изменения, а затем я должен отображать этот набор данных в HTML, захватывая существующий элемент DOM, дублируя его, заполняя элементы данными из этого установить с использованием имен классов или других идентификаторов элементов, а затем добавить их обратно в DOM.

Имейте в виду, что любой объект (JSON) в этом наборе данных может иметь до 1000+ дочерних объектов, и может быть до 10000+ родительских объектов, так как вы можете видеть, что может быть экземпляр, в котором возвращено набор данных вверх по направлению к 1,000,000 = > 10 000 000 точек данных или больше.

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

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

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

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

Это не типичный вариант использования HTML/DOM, поскольку я знаю, что существуют ограничения, но что это такое? Мы все еще ограничены примерно 3000-4000 элементами?

У меня есть ряд связанных подзапросов для этого, m up но я подумал, что было бы неплохо поделиться некоторыми мыслями с остальной частью сообщества stackoverflow и попытаться объединить некоторые сведения об этой проблеме.

Что такое "разумное" количество элементов DOM, которое может обрабатывать современный браузер, прежде чем он начнет становиться медленным/невосприимчивым?

Как я могу сравнить количество элементов DOM, которые может обрабатывать браузер?

Каковы некоторые стратегии для обработки больших наборов данных, которые необходимо визуализировать (помимо разбивки на страницы)?

Являются ли шаблоны шаблонов, такие как усы и дескрипторы, более эффективными для рендеринга html из data/json (на интерфейсе), чем использование jQuery или регулярных выражений?

Ответ 1

Ваш ответ: 1 или миллионы. Я собираюсь скопировать/вставить ответ из аналогичного вопроса в SO.

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

Никаких ответов, приведенных здесь, не будет правильным, так как это зависит от многих факторов, характерных для вашего приложения. Например. тяжелый или маленький Использование CSS, размер разделов, количество фактической визуализации графики требуется для каждого div, целевого браузера/платформы, количества событий DOM слушателей и т.д.

Просто потому, что вы можете это не значит, что вам нужно!:-) "

Посмотрите: сколько у вас может быть div, прежде чем dom замедляется и становится неустойчивым?

Это действительно неопровержимый вопрос, при котором слишком много факторов на слишком многих углах. Я скажу это, однако, при загрузке одной страницы я использовал javascript setinterval в 1 мс, чтобы постоянно добавлять новые divs на страницу с индексом, увеличивающимся на 1. Мой браузер Chrome просто прошел 20 000 и использует 600MB Ram.

Ответ 2

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

Почему

Соответствующим уравнением является это: где N - количество узлов, байты _N - это суммарные байты, необходимые для представления их в DOM, диапазон индексов node - n ∈ [0, N), bytesOverhead - это объем памяти, используемый для node с абсолютной минимальной конфигурацией атрибута и innerHTML, а bytesContent - это объем памяти, используемый для заполнения такого минимального node.

bytes _N= Σ ^N (bytesContent _n + bytesOverhead _n)

Значение, заданное в вопросе, - это максимальное значение N в наихудшем карманном устройстве, операционной системе, браузере и условиях работы. Решение для N для каждой перестановки не является тривиальным. Уравнение выше показывает три зависимости, каждая из которых может кардинально изменить ответ.

Зависимости

Средний размер node зависит от среднего количества байтов, используемых в каждом для хранения содержимого, например текста UTF-8, имен атрибутов и значений или кешированной информации.
Средние накладные расходы объекта DOM зависят от пользовательского агента HTTP, который управляет представлением DOM каждого документа. W3C Часто задаваемые вопросы по объектной модели документа:" Хотя все реализации DOM должны быть совместимы, они могут значительно различаться в размере кода, требовании памяти и производительность отдельных операций.
Память, доступная для использования в представлениях DOM, зависит от используемого браузера по умолчанию (который может варьироваться в зависимости от того, какие браузеры или пользователи предпочитают карманные устройства), переопределение пользователя браузера по умолчанию, версия операционной системы, объем памяти карманного устройства, общие фоновые задачи и другое потребление памяти.

Строгое решение

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

Количество байтов на символ должно быть проверено как для значений атрибутов, так и для внутреннего текста UTF-8 (или любого другого), чтобы получить четкую пару факторов для вычисления (1).

Доступная память также нуждается в тестировании в самых разных условиях, что само по себе является крупным исследовательским проектом.

Особое значение выбранного N должно быть ZERO для обработки наихудшего случая, поэтому можно было бы выбрать определенный процент типичных случаев контента, структур node и условий времени выполнения. Например, можно взять образец случаев, используя некоторую форму рандомизированного in situ (в нормальных условиях окружающей среды) исследования и найти N, который удовлетворяет 95% этих случаев.

Возможно, множество случаев может быть проверено указанными способами и результатами, помещенными в таблицу. Это будет прямым ответом на ваш вопрос.

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

Более практическое оценивание

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

Рассмотрим сотовый телефон, который разрешает 1 Гбайт для DOM, потому что нормальные условия эксплуатации используют 3 Гбайта из 4 ГБ для вышеупомянутых целей. Можно предположить, что средний расход памяти для node будет следующим, чтобы получить цифру шарового поля.

2 байта на символ для 40 символов внутреннего текста за node
2 байта на символ для 4 значений атрибутов по 10 символов
1 байт на символ для 4 имен атрибутов по 4 символа
160 байт для служебных данных C/С++ node в менее эффективных случаях

В этом случае N _{худший_карт} наихудший наименьший узел,

= 1,024 X 1,024 X 1,024
  / (2 X 40  +  2 X 4 X 10  +  1 X 4 X 4  +  160)

= 3,195,660 . 190,476.

Я бы, однако, не создал документ в браузере с тремя миллионами узлов DOM, если бы его вообще можно было избежать. Рассмотрите возможность использования более распространенной практики ниже.

Общая практика

Лучшее решение - оставаться далеко ниже того, что может быть N _{most_case}, и просто уменьшить общее количество узлов до степени, используя стандартные методы разработки HTTP.

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