Близится самое тяжёлое время для приложения усилий у большинства людей. Это праздники. Несмотря на него, продолжим тему исследования свойств браузеров, потому что праздники закончатся, а знание сохранится.

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

Отдельно о скрипте. Он не есть самый лучший пример для приложения - лучшая версия вскоре будет написана, вероятно, в начале января. Кстати, её находят лучшей среди имеющихся скриптов и в последние 2 месяца активно находят, скачивают и размещают у себя на сайтах. Сейчас у него (речь идёт о версии с эффектом приближения снежинок) довольно сложное управление параметрами, которое будет упрощено, и в результате описываемых исследований будет попытка добавить функцию определения мощности системы - насколько быстро в ней исполняются скрипты и насколько много можно выпустить движущихся снежинок. Почему так неуверенно об этом сказано - потому что нагрузка системы должна выполняться косвенно, прямой функции доступа скрипта к системным характеристикам нет. А так как нагрузка изменяется, скрипт может сделать неправильные выводы, если его хорошо не протестировать и не предусмотреть все случаи. Поэтому процесс будет долгим, и первую версию нельзя будет гарантировать удачной.

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

Динамические свойства и характеристики браузеров были измерены на примере скрипта падающего снега на странице http:// javascript.aho.ru/example/xmp002/falling-snow-2.htm . За показатель перегрузки принимался процент отставания таймера, который крутился в непрерывном цикле по setInterval( ..., 70); (70 мсек.). Начальные установки в командной строке первого поля ввода подобраны так, что начать измерения можно, нажав на вторую кнопку на странице, "Start snow by command". Далее, не меняем никаких параметров, кроме unitsNum, указывающего число снежинок и не нажимаем на 3-ю кнопку, которая исказит начальные установки. Все дальнейшие измерения, описанные в статье, выполнялись на наблюдении 3 чисел:
  1) unitsNum, числа снежинок в скрипте анимации,
  2) Cpu Usage - процента реальной загрузки системы, которая извлекается и усредняется из графика системного монитора задач, если система - Windows. Открыть его можно по комбинации клавиш Ctrl-Shift-Esc, 3-я вкладка "Performance" ("Производительность"),
  3) усреднённое (умозрительно) за период 10-20 с число "Отставание", указывающее, на сколько процентов запаздывают показания таймера от показаний часов в среднем за последние 1.5-2 с.
  Следующее число в мониторе, "Разброс", говорит о разбросе показаний, и подсказывает, насколько процент запаздывания был нестабильным. Оно помогает сделать правильные измерения, но не используется в отображении конечных результатов.

Для различных процессоров и систем, естественно, будут различные показания, и это может быть предметом отдельных "открытий". Например, известно было по наблюдениям первой версии скрипта год назад, что особенно "тормозит" Firefox (1.06) а на системе со слабой графической картой от тормозит сильнее, чем IE на них же. Но рассматривать поведение на системах разной мощности не входит в настоящие планы, потому что измерения не автоматизированны и по каждой группе браузеров занимают длительное время. Тем не менее, даже исследование на 1 системе или сравнение её с другой, которое читатели смогут произвести самостоятельно, даст важные знания о нагрузочной способности браузеров. В результатах они сведены в таблицу и диаграммы Excel в достаточно наглядном представлении. Затем (в следующих выпусках рассылки) они будут использованы для построения алгоритма, подстраивающегося под производительность системы.

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

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

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

Измерения на другой, равной по мощности и характеристикам системе (Первая - Athlon 2100+, DDR333, GF4MX440, вторая - Athlon 2000+, DDR333, Matrox G450DH, 2 монитора, все измерения при недозаполненной ОЗУ, в WinXP SP2), показывают, что показатели производительности могут различаться по непредсказуемым и невычисляемым причинам. То ли быстродействие драйверов, то ли что-то другое, но приводит к отклонениям в относительной производительности даже для одних и тех же дистрибутивов браузеров. Во второй системе для IE и Оперы существует особенное поведение запаздывания таймера при малых нагрузках. Все измерения показывают запаздывание на 10%, даже при 1 снежинке. Нечто подобное наблюдалось на первой системе только в Опере-7 при 1-10 снежинках и отражено на графике "CPU Usage-Flakes".

Наконец, у IE и Оперы 7-8 видна особая "методика запаздывания" таймера: если нагрузка начинает превышать 50%, запаздывание таймера выходит на "плато" - величину 14-15%, которое продолжается довольно долго - до 70-75% нагрузки. И это надо считать работоспособной областью скрипта, поскольку до перегрузки процессора далеко. У Оперы=9 это "плато" очень короткое, в пределах 70-75% CPU Usage (лучше всего видно на графике "CPU Usage-overtime percentage"), а FF показывает отличные результаты по точности отмеривания времени таймера. В нём встроена методика (видно по поведению процента перегрузки, который с ним бывает меньше 0) подгонки времени работы таймера - если ему пришлось запоздать, в последующее время, вплоть до нескольких секунд, его задержки уменьшаются, чтобы восстановить точность хода, и начинают невосстановимо запаздывать, только если ресурсов системы не хватает. (Возможно, это работает только для таймеров типа setInterval?)

Теперь приведём графики, на основании которых сделаны такие интересные выводы. В них уже лежит способ вычисления производительности при доступности только 2 чисел из 3, но (снова выводы) надо создать для системы перегрузку и сделать это 1-3 раза, чтобы определить, в какой точке характеристики мы находимся. Кроме того, надо быть уверенным, что условия опыта не изменились, что не возник другой посторонний процесс за время измерений. Чего, конечно, гарантировать нельзя, и нужно думать, как создать алгоритм, приводящий хотя бы к некатастрофическим ошибкам в выводах. И, конечно, для вычисления оптимальной нагрузки нужно учитывать тип и даже версию браузера или группу версий. Так, Опера-9 ведёт себя немного иначе, чем прежние версии.

Графики находятся в архиве http:// javascript.aho.ru/ example/ xmp002/nagruzkaFallSnow.zip , 38 Kb, в котором находится как Excel-таблица с графиками, так и рисунок *.PNG, отражающий всё содержимое листа для тех, у кого Excel не установлен. Или его можно посмотреть по ссылке http:// javascript.aho.ru/ example/xmp002/nagruzkaFallSnow.png . Все измерения проделаны в 1-й системе компьютера (2100+MHz, DDR333) на 7 вариантах браузеров: IE7, IE6, FF1.07, FF2, Op7.54, Op8.01, Op9.10.

Описание графиков. Из одной таблицы для наглядности обзора сделаны 2 графика и 1 диаграмма. Только 1 зависимость из 3 может быть получена браузером с помощью скрипта, 2 других используют системные показания CPU Usage - загруженности процессора. Поэтому в реальности придётся о производительности системы судить из функции типа такой, как показано на 1-й зависимости "Browser times overtime-Flakes". Многоядерные системы могут даже не смочь загрузить всю свою мощность вычислениями, и расчёт будет вестись не для 100%-й, а для предельной нагрузки, возможной для браузерного окна.

В силу своих особенностей, браузеры на движке Gecko уверенно показывают момент 100%-й нагрузки процессора - достаточно сделать 2 измерения в области перегрузки и экстраполировать результаты. Для других браузеров надо сначала условиться, какой момент считать 100%-й загрузкой. Для других браузеров из диаграммы снизу слева видно, что по 2 измерениям можно получить точку 100%-загрузки, если брать измерения с не менее 80% отставания таймера для IE6-7, Оперы-7, неизвестно - для Оперы-8 (не проделаны измерения в нужной области), и с не менее 30% для Оперы-9. Неизвестно, будут ли эти признаки диаграммы повторяться в других системах, но в качестве рабочей гипотезы такую модель принять можно.

Есть в ней для не-Гекко одно неудобство. Эти браузеры при 100%-загрузке создают сильное запаздывание таймера. Это значит, что анимация будет идти во столько медленнее. Избежать этого можно, выбирая для них точку небольшого или нулевого запаздывания. Глядя на диаграмму, видится удобным использовать район 15%-го отставания. Попасть в него можно, найдя 2 точки между 15%- и 80%-запаздыванием. Большой потери от недостаточной скорости вычислений не будет. Но важно, чтобы вычисление было надёжно и просто. Это всё уже относится к выбору методики определения оптимальной загрузки и будет рассматриваться в следующем выпуске в скрпите падения снега с автоподстройкой мощности.

Далее перечислим другие сводные таблицы и дополнительные данные, полученные из измерений на 1-й и второй системах.

Из таблиц получаем 2 ряда чисел, которые можно считать пределом нагрузки (в числе снежинок заданного размера) конкретной системы и компьютера скриптом. Первое получаем из скрипта (по проценту перегрузки), второе - по CPU Usage, недоступное из скрипта. Учитывая то, что часто в IE/Опере видим "плато" с 15%-запаздыванием показаний таймера, условимся считать, что процессор нагружен при проценте перегрузки, равном 17% (как вычисляется процент перегрузки, вряд ли стоит долго объяснять всё написано в коде, но ниже отведём 1 абзац на описание). При этом FF будет работать с реальной перегрузкой по показаниям CPU Usage, а остальные - с 70%-й загрузкой, оценка будет неточная. Но она уже позволит свести весь график к 1 числу. В следующем списке приведены предельные количества снежинок при заданных условиях опыта. Предел нагрузки (числа снежинок) в данном опыте (c 17%-перегрузкой/100% нагрузкой процессора):

Из первой колонки с определённым коэффициентом можно получить вторую в зависимости от версии браузера. Остаётся найти точку этого 17%-отставания таймера. Или найти более удобные алгоритмы вычисления момента 100%-й загрузки процессора.

Первое число в мониторе, "Отставание", или процент отставания таймера (пояснение для тех, кто не желает посмотреть скрипт) вычисляется как среднее между максимальным и минимальным значениями отставания за несколько (22) измерений в течение 1.6 секунды. Приблизительное среднее за период 10-20 с, вошедшее в таблицы, бралось от этой полусуммы. Второе число - разность между минимальным и максимальным.

Дополнительные измерения. Интересно было узнать, насколько нагружают процессор скрипты в фоновом режиме. Взяты нагрузки (CPU Usage) примерно в 80% при открытом окне, затем окно свёрнуто и снова измерен процент нагрузки. Отношение CPU Usage при развёрнутом / минимизированном окне (%).

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

Измерение скорости математических вычислений.

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

Скрипт с исключёнными обращениями к DOM - http:// javascript.aho.ru/example/xmp002/falling-snow-21a.htm.

Как ожидалось, она значительно меньше, чем нагрузка анимации, потому что позволяет запустить во много раз больше "виртуальных" (несуществующих) снежинок. Попробуем подобрать такое количество снежинок, точнее, число unitsNum, чтобы нагрузка стала равной 50%. Тогда отношение скорости вычислений к скорости анимации будет равно отношению числа виртуальных снежинок к числу снежинок при 50% из графиков Excel минус 1 (потому что первое измерение было с вычислениями). (50% выбрано, потому что в не-Гекко 50%-загрузка при чистых вычислениях никогда не достигается.) Плюс эти числа надо умножить каждое на свой коэффициент отставания, чтобы учесть, что измерения произведены за более долгое время.

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

В Гекко и на вычислениях продолжает действовать механизм корректировки таймера. (Интересно, если перейти с setInterval на setTimeout, коррекция сохранится?) В Опере он работает, видимо, частично. Вообще, стоит посмотреть на график зависимости виртуальных снежинок от нагрузки в Опере-9, он своеобразен.

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

Получаем, насколько медленнее идёт отрисовка (3-я колонка). Для примера, строчка для IE7 рассчитывается так: (1750*(100+95)/100)/(30*1.15)-1=98 . Коэффициент 1.95 взят из отставания таймера без анимации (4-я колонка; правда, с другого компьютера, поэтому результаты не очень точны, они показывают примерное соотношение скоростей), коэффициент 1.15 - из диаграммы Зкселя.

Выводы из расчётов. Главное - вычисления в скрипте с массивами и синусами во много раз быстрее анимации. На разных системах даже при похожих характеристиках и одних и тех же дистрибутивах (Opera 7.54) скорость вычислений может различаться вдвое. Трудно предположить, чем это может быть вызвано. При экспериментах память системы не освобождалась от других программ и система не перезапускалась. Возможно, это уже зависит от особенностей процессоров и их кеша. Так как скорость на системах различается, а конечные числа получены из данных двух систем, доверять им можно с точностью +-100%. Опера достигла очень хороших показателей как по анимации, так и по вычислениям. Более интересны не конечные данные (соотношение), а раздельно скорости анимации и вычислений во вторых колонках последних таблиц.

Для оценки объёма вычислений приведён код основного цикла по всем виртуальным снежинкам из страницы последнего эксперимента, falling-snow-21a.htm . Из него убраны все обращения к DOM и заменены на бессмысленные переменные c и d, служащие только в качестве аргументов операторов, чтобы сохранить объём вычислений.

for (i=0;i<unitsNum;i++){
  if(!snow[i].present)continue;
  var d=(snow[i].posY+=snow[i].sink+lftRght[i]
    *Math.sin(crds[i])/3)+'px';
  crds[i] += x_mv[i];
  var b=snow[i].posX+lftRght[i]*Math.sin(crds[i]);
  var a=marginBottom+(snowOnScreen?0:scrlTop)-snow[i].posY;
  var c=0;
  if(a<=0 || b>marginRight-c-25)
    {snow[i].style.visibility='hidden';
    newPosSnow(randomMaker((marginBottom-3*c)/2),i);continue;}
  var d=b+'px';
  if('IMG'=='IMG')d=d=c/1.6;
  else snow[i].style.fontSize=snow[i].size;
  if(a<=9.5*c){if(ie5)d=opac*a/(9.5*c)*100;
  else if(ns6||opera9)d=opac*a/(9.5*c);}
}

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

Полученную методику измерения производительности можно использовать при анализе дугих скриптов.

Обсуждение темы и разбор вопросов ведётся в теме форума.

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