Сколько div вы можете иметь до того, как dom замедляется и становится неустойчивым?

Я разрабатываю приложение jQtouch, и каждый запрос, выполненный через ajax, создает новый div в документе для загруженного содержимого. Показывается только один div.

Сколько div может быть у меня до того, как приложение начнет не реагировать и замедлить?

У кого-нибудь есть идеи по этому поводу?

EDIT: приложение iPad, работающее на Safari, и оно будет меньше 1000 div с очень базовым контентом

Ответы

Ответ 1

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

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

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

Ответ 2

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

Разработано из HTML или создано динамически в JavaScript?

Анализ HTML означает, что у вас есть LARGE html-источник, и это может привести к зависанию браузеров. Сгенерировано в JS удивительно быстро, даже в Internet Explorer, который является самым медленным из всех браузеров для JS.

Ответ 3

Как говорили другие, на самом деле ответа нет.

Однако в этом разговоре о API Карт Google версии 3 динамик несколько раз поднимает число десять тысяч в качестве основного порог для несчастья браузера.

http://code.google.com/apis/maps/documentation/javascript/

Ответ 4

Без определения конкретной среды невозможно ответить на ваш вопрос.

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

Ответ 5

5.

Это действительно зависит от механизма отображения javascript используемого вами браузера. Если мы увидим некоторый пример кода, мы можем подробнее рассказать о вашей проблеме.

Ответ 6

Он будет зависеть от ограничений памяти, установленных браузером. Почему вы не можете перерабатывать DIV?

Ответ 7

Единственный раз, когда я видел, что современный браузер замедлялся из-за слишком большого количества элементов DOM, приходилось проверять script, который пытался "нарисовать", используя 1x1 divs, абсолютно позиционированных с цветом фона. Этого было достаточно, чтобы калечить Firefox.

Ответ 8

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

Как сказал Харпо, 10K, вероятно, хороший потолок. Когда-то я заметил проблемы с скоростью около 4K div, но аппаратное обеспечение улучшилось с тех пор.

И, как сказал Neil N, добавление divs через скрипты лучше, чем наличие огромного HTML-источника.

И, чтобы ответить на комментарий Harpo, один из способов "разбить его", чтобы JS не блокировал страницу и не вызывал ошибку "страница работает медленно", заключается в вызове таймера в конце каждого "добавления div", и таймер, в свою очередь, снова вызывает функцию "добавить div".

Теперь, мой вопрос: можно ли "нарисовать", чтобы вам не нужно было добавлять тысячи div? Это можно сделать с тегом canvas с некоторыми браузерами, но я не думаю, что это возможно с VML (проект excanvas) в IE. Или это? Я думаю, что VML "рисует", добавляя новые элементы в DOM, после чего вы можете использовать DIVs, если только это не простая форма.

Можно ли изменить источник изображения с помощью скриптов? (изображение в DOM, конечно, не оригинальное изображение на сервере.)