Таблица 8.4. Результаты тестирования

Такова методология проверки. В следующем разделе мы обсудим ее результаты.

8.4.3. Как уменьшить объем используемой памяти в 150 раз

Выполняя тестирование и пользуясь данными, предоставляемыми Windows Task Manager, можно сделать вывод о том, что объем используемой памяти зависит от алгоритмов, выбранных посредством флажков опций. Результаты проверки приведены в табл. 8.4.

Тестирование производилось на рабочей станции с тактовой частотой процессора 2,8 ГГц и 1 Гбайт оперативной памяти, работающей под управлением операционной системы Windows 2000 Workstation. В качестве браузера был выбран Internet Explorer 6. Во всех случаях начальное потребление памяти составляло приблизительно 11,5 Мбайт. Информация об использовании памяти отображалась в столбце Mem Usage на вкладке Processes программы Task Manager (см. раздел 8.4.1).

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

Необходимо также заметить, что выбор конкретных программных решений оказывает огромное влияние на объем занимаемой памяти. Рассмотрим результаты более подробно. При трех сочетаниях флажков опций после отображения и удаления всех компонентов clickBox объем памяти оказывался менее 15 Мбайт. При остальных наборах опций это значение возрастало до 80, 160 и даже до 430 и 580 Мбайт. Учитывая, что сам браузер потребляет 11,5 Мбайт памяти, размер дополнительно использованной памяти лежал в пределах от 3,5 до 570 Мбайт, т.е. мы можем сократить его в 150 раз, правильно выбрав программные решения. Стоит также отметить, что браузер продолжал функционировать при любой утечке памяти.

Глава 8. Производительность приложения 343

Ни один из алгоритмов нельзя признать виновником происходящего. у[ежду ними существует очень сложная взаимозависимость. Сравнивая, например, проверки A, D и F, мы видим, что переключение значения опции Reuse DOM Nodes дает огромную экономию памяти {больше 90%), в то же время переключение Unlink On Hide приводит к тройному увеличению ее похребления. В данном конкретном случае причины происходящего понятны — поскольку связи для узлов DOM разрываются, они не могут быть найдены путем вызова document .getElementById(), следовательно, их невозможно использовать повторно. Аналогично, изменение значения опции Unlink on Hide приводит к увеличению потребления памяти по сравнению с исходной конфигурацией (проверки С и А). Перед тем как объявлять опцию Unlink on Hide виновницей излишнего расхода памяти, сравним проверки Е и G — в правильном контексте она дает некоторый положительный результат.

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

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

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

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

Использование типичных программных решений упрощает задачу создания тестовых сценариев. Написание программ или сценариев для тестирова-