Динамические свойства и характеристики браузеров были измерены на примере скрипта падающего снега. За показатель перегрузки принимался процент отставания таймера, который крутился в непрерывном цикле по setInterval( ..., 70); (70 мсек.).

Имея инструмент измерения перегрузки процессора, первым делом понадобилось посмотреть, как ведут себя показатели перегрузки в разных браузерах, чтобы впоследствии при разных перегрузках представлять, в какой точке характеристики мы находимся, насколько надо уменьшить нагрузку процессора, чтобы анимация пришла в норму. Измерения велись на странице http://js2.ru/example/xmp002/falling-snow-2.htm .

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

Интересно посмотреть, как ведут себя браузеры при повышении нагрузки. Сразу оговорим условия опыта. Замечено, что в IE6 отисовка летающих букв была намного медленнее, чем в IE7. Чтобы не портить картину случайным выбором букв, в эксперименте участвовали только рисунки (снежинок). При этом условии результаты IE почти не отличались. Опера 7-8 работатла очень быстро, но надо учесть, что она не поддерживает прозрачность, а это отображать традиционно труднее. Опера 9 догнала по быстродействию 7-ю и была примерно в 1.3 раза лучше IE. FF1.07 представлял довольно жалкое зрелище на фоне остальных, но в пределах своей нормы с работой справлялся. В FF заметна интересная методика работы таймера: если он сначала запаздывает по внешним причинам (даже на протяжении 3-4 секунд), то затем интервалы его обязательно сокращаются и догоняют часы (если смогут)! Такой особенности в остальных браузерах нет. В Опере-9 виден радикально иной подход к отсчёту таймеров, чем в прежних - она ухитряется соблюдать правильность хода таймера, насколько может, но при этом не видно периодов уменьшения интервалов с целью догнать часы. В Операх также видна другая особенность работы таймера или данного скрипта - забор процессорного времени происходит "квантами", примерно равными 10% мощности процессора. Из-за этого наблюдается некоторая ступенчатость характеристики реальной загрузки процессора. Но в скрипте нет такой особености  и в других бр-рах она не проявляется.

   Наконец, у IE и Оперы видна особая "методика запаздывания" таймера: если нагрузка начинает превышать 50%, запаздывание таймера выходит на "плато" - величину 14-15%, которое продолжается довольно долго - до 80-85% нагрузки. И это надо считать работоспособной областью скрипта, поскольку до перегрузки процессора далеко.

В следующем списке приведены предельные количества снежинок при заданных условиях опыта.
Предел нагрузки (числа снежинок) в данном опыте (c 17%-перегрузкой/100% нагрузкой процессора):
IE7:   55/110
IE6:   45/90
FF1.07: 40/35
FF2:    80/70
Op7.54: 70/150
Op8.01: 150/300?
Op9.10: 90/100
Условия опыта соблюдались во всём одинаковые - объём программ в ОЗУ, размер окна браузера, активность окна. Усреднялись показания при устоявшемся процессе за период 10-20 сек. . Все результаты - в таблице (Excel), процент загрузки процессора (Athlon-2000+, ОЗУ DDR-266) и показания отладочного монитора, которое означает процент отставания таймера.
   Процент отставания, в свою очередь, считался как среднее между максимальным и минимальным значениями отставания за несколько (22) измерений в течение 1.6 секунды. И приблизительное среднее за период 10-20 с бралось от этой полусуммы.

Дополнительные измерения. Интересно было узнать, насколько нагружают процессор скрипты в фоновом режиме. Взяты нагрузки примерно в 80% при открытом окне, затем окно свёрнуто и снова измерен процент нагрузки.
Отношение загрузки развёрнутого/минимизированного окна (%).
FF2: 85/30
Op8.01: 80/40
Ie6: 85:35

В приложенном файле можно найти таблицу Excel c диаграммой перегрузок в зависимости от числа снежинок для 7 браузеров и, для тех, кому затруднительно посмотреть её в Экселе, рисунок (PNG) всего содержимого листа.

Добавление: к таблицам нагрузки добавил диаграмму "загрузка (процессора)-перегрузка (скриптом процессора)". Комментарии в 12-м по счёту сообщении.

Это сообщение отредактировал(а) 12345c - 3.3.2008, 12:52

Присоединённый файл ( Кол-во скачиваний: 1 )
 nagruzkaFallSnow.zip 37,80 Kb

мда 12345c чувствую тебе на праздники отдохнуть хорошо надо... 
нет я конечно понимаю статистика к примеру по innerHTMLvsDOM при создании select
а вот использование анимации на странице c ее автоподстройкой под камешек, это имхо немного не того.
браузер ведь это покачто просто браузер

искренне надеюсь что не огорчил тебя, а отдохнуть тебе надо, 

12345c, 

Ничего не понял
При меньшем количестве снежинок нагрузка больше?

Или что значит 17% перегрузка? 
Проц летит вниз со скоростью 1.17g? 

12345c, что-то как-то... Смогешь оценить реальную загруженность процессора при всех вышеописанных нюансах?
Есть еще такой нюанс: я не мог загрузить свой процессор на 100% в одном браузере при любом количестве снижинок, максимально, что показывает диспетчер, это значение 50%. Не знаю, может быть сказывается HT.

Core Duo (T2050) двух ядерник с 1Гб оперативы, загружаеться только одно ядро под 90% на 150 снежинках как в ИЕ6, так и в ФФ2.
12345c, это всё интересно, но главное ты не сказал, а что точно означает "среднее" и "разность"? Я так понял из текста "отставание таймера" в процентах?

P.S. разработка интересная, но ИМХО скрипт не юзабелен если загружает проц более чем на 10%, следовательно практическое применение такому монитору найти сложно...

Sardar, 
Разработка вообще занимательная, однако слишком все шатко-валко. У меня при 1000 снежинках процесс загружен на 50%... странно все это.
Но я как-то упомянул в соседней теме, что реальную производительность машины мы не знаем, поэтому "отставание таймера" здесь дает только далеко приблизительную оценку.

Это я назвал в мониторе так кратко, но в тексте пояснил, что значит первое число:

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

Сразу скажу, что вычисление перегрузки процессора я ещё не получил, но она прямо следует из этих графиков. На пути к решению я сделал такой алгоритм (в http://js2.ru/example/xmp002/falling-snow-2.htm ).

Вычисляем отставание таймера от часов за несколько периодов. В исследуемом скрипте это число периодов определяет время усреднения - переменная tDebug=1600 , которую затем делим на stepTime (=70) - шаг таймера. Поэтому в эксперименте был период усреднения в 22 периода таймера (если он запаздывал, то время было больше, но это детали). Далее, в программе организовали массив aDTimeN, в который пишем среднюю разность показаний часов за tDebug/stepTime (=22) периодов. Это даёт возможность сгладить всплески задержек за короткие промежутки времени. Но этого мало - надо отсечь нестабильности. Для этого вычисляем 2 числа по массиву (именно для этого понадобился массив, а не просто очередь): максимальное отставание таймера и минимальное.
И это не всё - для удобства анализа берём процент отставания, и нас интересует тоько 2 числа: полусумма предельных отставаний и полуразность. Последнее - показатель нестабильности, и его в теме вообще не анализировали, а первое называлось "Процент отставания", и его я заносил в таблицу вместе с показаниями CPU Usage.

где pDigit(n,x) - функция взятия числа x с точностью n знаков после запятой.

Действительно. Может, процессор 2-ядерный, и он показывает загрузку только 1 ядра? Если да, то это, кстати, надо будет учесть. 

smartov, поясняю на вышеизложенном дальше, что такое "17%-перегрузка". На опытах я обнаружил, что не-гекко-браузеры имеют плато на графиках перегруженности, имеющее величину примерно 16%. (Таймер запаздывает от часов на 16%.) Момент дальнейшего роста перегруженности я предложил считать точкой полной загрузки процессора (на самом деле это 70-85%. Что-то ведь надо же считать точкой загруженности? Загруженность на 100% для IE, судя по графикам, происходит в области больших отставаний таймера и никак характерно не выражается. И вот я привёл 2 числа: число снежинок, когда перегрузка - 17%, и число снежинок, когда CPU Usage=100% (для FF оно меньше). И вообще, зачем я это объясняю, ты график смотрел? )
Тут некуда деваться. Имеем как факт "неюзабельный" скрипт, дающий перегрузку процессора. Имеем в скрипте способ регулировки нагрузки. И тогда, подключив вычисление перегрузки, можем настроить его так, чтобы на данной машине он работал на 50-60%. Обрати внимание - когда мы не имеем возможности этого делать, ты категорически заявляешь про 10% - и правильно, потому что 10% для 3ГГц - это 100% для 200 МГц - нижняя мыслимая граница мощности системы. Тут же появляется возможность поднять планку в 5-6 раз (при большом желании - в 8-10) и при этом не завалить все менее мощные системы.


Это сообщение отредактировал(а) 12345c - 3.3.2008, 12:53

  
12345c, ты бы лучше в геймдев или в разработку симуляторов подался, уж больно твои интересы чужды в мире JS'a и вообще вебтехнологий... 

До меня просто не доходит каким макаром можно больше тормозить на меньшем количестве объектов %)

17% и 100% - это к разным переменным относятся. Первое - к проценту перегруза, который вычисляется скриптом (dTimeMin+dTimeMax)*50-100, а значит, легко получим), второй - процент системной загрузки процессора, недоступный из скрипта. Написал их рядом, чтобы можно было видеть, как они соотносятся для разных бр. .

12345c, процессор 1-ядерный, но с технологией HT, сколько бы не увеличивал количество объектов - все равно 50%.
А ты пробовал расчитывать нагрузку с отставанием таймера при мат. вычислениях, не касаясь отрисовки объектов? Если будет время+желание, посмотри, мне интересно узнать твои результаты в данном вопросе и одновременно оценить корректность в своих.

Nicholas_S, если подумать, то эта загрузка 50% ведёт себя как 100%, и никак не сможем определить реальное число. И не надо - интересует только способность показывать перегрузку.

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

Sardar: интересно, попробуй запустить скрипт в 2 разных окнах на 2-ядерном процессоре - будет ли больше 50% загрузки. Если нет, то в 2 разных бр-рах с той же целью.

Добавил к Экселю диаграмму "загрузка - перегрузка" (изв. за каламбур). Она хорошо показывает, чётко ли работает скрипт с перегрузкой. Упомянутая особенность Гекко приводит к тому, что он отрабатывает режим перегрузки идеально - диаграммы имеют вид буквы "Г". Остальные начинают запаздывание таймеров задолго до перегруженности системы, с характерными "плато". Опера-9 героически стремится к букве "Г", у неё это почти получается. ;) Итого, в не-Гекко придётся искать точку достаточной загруженности скрипта, следя за 17%-перегрузкой, наверное. 

Nicholas_S, сделал эксперименты по работе скрипта изменения перегрузок только с математическими рассчётами. Заодно, оценил, какая доля работы в браузере для данного скрипта занята рассчётами, а какая - выводом изображений. Здесь особо интересных результатов нет - просто скрипт подтверждает, что анимация происходит в паузы, а рассчёты - между паузами. Поэтому в промежутках между занятостью машины рассчётами видим пустую паузу на CPU Usage, ничем не занятую. Загрузка стремится к 100%, но не достигает их. Из этого несложно оценить долю рассчётов и анимации, подобрав такое количество "виртуальных" снежинок, чтобы нагрузка стала 50%. Приведу эти цифры для разных браузеров. (Вычисления были на другой машине примерно такой же мощности и скорости памяти (Athlon 2ГГц, DDR333), но 2-мониторная, с другой видеокартой. Вероятно, поэтому, или по другой причине, Опера и IE имели особенность, что всегда имели процент отставания таймера 10% при малых нагрузках. Примерно как Опера-7 на прежних графиках, но даже при 1 "снежинке" (несуществующей) - всё равно.

Как переделан скрипт. Убраны все обращения к объектам, связанным с DOM, а вместо них поставлены переменные (c,d). Таким образом, математические операторы сохранились. Образец для просмотра и экспериментов - http://js2.ru/example/xmp002/falling-snow-21a.htm .

Вот основной цикл:


Таблица 50%-загрузки системы. (при числе "виртуальных" снежинок). При этом "Среднее" (процент отставания таймера) - 100, как и должно быть по описанной модели.

IE6 - 480
IE7 - 2100 (вычисления значительно быстрее)
Op7.54 - 2200 (но процент отставания таймера - 65. Корректирует?)
Op9.01 - 1500 (при проценте отставания - 37. Её поведение на этом графике при других процентах загрузки заслуживает внимания.)
FF1.07 - 1200 (процент отставания - 0. Этот точно корректно корректирует запаздывание таймера.)

(Интересно, если перейти с setInterval на setTimeout, коррекция сохранится?)

Смотрим на прежние графики, когда была 50%-загрузка.

IE6 - 27
IE7 - 30
Op7.54 - 170
Op9.01 - 135
FF1.07 - 18

Значит, отрисовка снежинок медленнее вычислений для отрисовки (с массивами и синусами) во столько раз:

IE6 - 34
IE7 - 140
Op7.54 - 24
Op9.01 - 20
FF1.07 - 130

Интереснее, конечно, 1-я таблица с реальной скоростью вычислений и 2-я с реальной скоростью отрисовки.

Добавление: на  1-й (упомянутой в теме) системе замеры 50%-й загрузки показали (условных снежинок):
IE6 - 750
Ie7 - 1750
Op7.54 - 1200 (из того же дистрибутива)
Op8.01 - 3100
Op9.10 - 1900
FF1.07 - 1100
FF2 - 1250

Это сообщение отредактировал(а) 12345c - 3.3.2008, 12:54

...мда.. вопрос не актуален.. sorry
анимация сейчас лежит только на flash, редко на Java.. а скрипты уже давно не в теме..

...я так считал лет 5 назад . С ростом призводительности скриптов они могут занять скромное место в анимации. У них есть плюсы в доступности. Если отключить гиф- и флеш-анимацию, теряется только реклама и 1% непредусмотрительных флеш-деятелей. Если отключить скрипты, потеряются больше сайтов, на что немногие пойдут.

Добавлено @ 18:28 
(И Джаву, естественно, тоже отключают из-за глючности.)