Привет, ребята.
Выручайте подсказкой.
Собственно суть такая:
Есть дерево на странице - комопнент Dojo Tree.
Для того, что бы его построить нужно ему отдать модель, которая парсит JSON.
Сам JSON возвращаю из сервака AJAX-ом. Ну это все умеет сам Dojo. Моя задача всего лишь отдать в респонз правильный формат.
Каждая ветка запрашивает свое содержимое сама, т.е. я не тащу все дерево целиком за раз.
Так вот: все работало отлично до тех пор, пока пользователи не напихали в одну ветку аж 10000 элементов.
И того выходит, что при открытии страницы и отрисовки корня с его чилдренами браузер просит "остановить скрипт".
Вопрос заключается в том, как его обмануть: отрисовывать усе, но при этом, что бы он не ругался?
Можно ли поставить в цикле обработки чилдренов какое-то прерывание, что бы освободить основной поток, потому как понимаю, что проблема именно в удержании основного потока выполнения.
Т.е. например, если индекс цикла == 100, то приостановиться.
А может проблема в другом?..
В общем выручайте   

Если просит во время eval(your_json), то тут прямыми методами не сделаешь, уже в структуру проекта надо вмешаваться.

А если при отображении (возня со структуруой), то в 100% случаев помагает оптимизация (кода, процессов, подхода), не всегда эффективно, но практика показывает, что прирост есть всегда.
Совсем недавний пример: сделал пользовательскую таблицу - передаю массив как контент, а таблица сама делает сортировку, может получать события, отдает события и выбор, присутствует анимация и т.д. - джентельменский набор. Но процесс создания был периодичным, поэтому чистота кода не соблюдалась и при небольших массивах заполнения все работало неплохо - возможно, с небольшими притормаживаниями, что списывалось на анимацию (вставка, сортинг, удаление). Но когда в таблицу был помещен массив ~200-250 строк (и всего 3 поля), процесс заморозился и тоже браузер попросил "остановить скрипт" (по-моему, ФФ тоже высказал опасения). Сделал таймер - вставка заняла около 13 секунд для ИЕ7 и около 4 секунд для ФФ 3.5. Решал вопрос исключительно оптимизацией - исключил повторное вычисление переменных и функций, минимизировал селекторы и вывел их в предпроцессы, использовал более оптимальные решения для циклов, переборов и прочих "чисто js-шных штучек". Как результат - в конечном итоге тот же скрипт в ИЕ7 стал выполняться за 0.5-0.6 секунд, ФФ менее чем за 0.4 секунды. И только за счет оптимизации кода, не трогая структуру таблицы и массива (передаваемый объект - "ассоциативный массив" - достаточно сложный - передаю в нем заголовки, контент, сплит-поля, формат полей, сортировку).

Так что, возможно, можно повозиться в твоем коде и помочь с оптимизацией.

Спасибо, что я не один такой.
В большенстве своем этот код не мой, а dojo'евкий. И как оно там стрит дерево я могу посмотреть, да и поправить могу, но уж многовато его...
Я, собственно, грешу на вот это место:

где это цикл, а ему как раз отдаются вот те 10000 чилдренов.

так померяй

Не понял: а что мерять?
Валится на вот этом


у класса dijit.WidgetSet объекта dijit.registry, который является так сказать рееестром всех живущих ныне вайджетов. Добавление в которые происходит при создании такового, что мы как раз и видем вот в том методе с циклом.

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


и в конце этой функции такой вызов


Долго, конечно, но для временного решения работает. Заказчик сам виноват, что хочет в дереве видеть такое количество веток. Хотя он и сам не ожидал...
Все спасибо за то, что хоть смотрели данную тему.... 

сколько времени что выполняется. Искать узкое место

вообще, нужно было использовать Firebug profile перед вызовом функции дял постройки, и искать узкое место. 

Ну посмотрел я этим профайлером.
Больше всего времени и вызовов было на методе из Dojo - buildNodeFromText
что вполне логично, так как нодов-то у меня аж 10000!!!