Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

5. Используйте данные относительно использования памяти, полученные с помощью средств операционной системы и средств мониторинга на основе собственного кода, предоставляемых устройством. Для получения данных хронометража, а также данных по использованию памяти приложением, характеризующихся повышенным разрешением, во многих случаях могут быть привлечены системные вызовы операционной системы, использующие собственный код. Кроме того, для получения статистических данных, характеризующих работу программы, можно привлекать инструментальные средства мониторинга, написанные с использованием собственных кодов. Если вы создаете компоненты или приложения на основе собственного кода, то эти именно эти данные и являются тем, что вам нужно; в этом случае вам остается только засучить рукава и приступить к измерениям. Если же вы пытаетесь получить информацию о производительности приложения, создаваемого на основе управляемого кода, то ситуация несколько осложняется. Если данные об использовании памяти системой или приложением получены средствами операционной системы, то необходимо учесть, что поведение управляемой среды в отношении использования памяти лишь в общих чертах коррелирует с поведением системы. Ввиду периодического выполнения таких операций, как сборка мусора, кривая использования памяти, вероятнее всего, будет иметь пилообразную форму, соответствующую постепенному накоплению неиспользуемых объектов в памяти и последующему периодическому освобождению памяти от них в результате работы сборщика мусора. Тем не менее, эта информация вам может пригодиться, если вы пытаетесь выяснить причины утечки памяти, происходящей на протяжении длительных промежутков времени. Кроме того, вы можете вызвать сборщик мусора еще до измерения объема используемой памяти, однако поступать так следует лишь в целях тестирования; вызовы сборщика мусора непосредственно в коде при обычном выполнении приложения почти всегда приводят к снижению производительности. Как бы то ни было, для получения информации о расходе памяти непосредственно из операционной системы могут потребоваться системные вызовы, использующие собственный код, с последующей коррекцией результатов. Если же вы можете получить необходимые вам данные из управляемой среды, то все делается намного проще.

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

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

• Суммарное время выполнения

• Количество объектов, размещенных в памяти в процессе выполнения кода.

• Количество операций по сборке мусора, произведенных в процессе выполнения кода.

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

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

Технические рекомендации относительно того, как активизировать генерацию рассматриваемых показателей времени выполнения, содержатся в статье "Developing Well Performing .NET Compact Framework Applications" ("Разработка высокопроизводительных приложений .NET Compact Framework") на Web-сайте http://msdn.microsoft.com.

На момент написания данной книги указанная статья располагалась по следующему URL-адресу:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfperf.asp

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

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

Представленный в листинге 7.1 код прост в использовании и имеет небольшие размеры, благодаря чему его включение в мобильное приложение приведет лишь к незначительному увеличению накладных расходов. Этот код предназначен для использования в качестве универсального средства тестирования производительности, при помощи которого вы сможете быстро измерять временные характеристики своих кодов. Это позволит вам быстро оценивать, сколько времени выполняется тот или иной участок разрабатываемого кода, и обнаруживать узкие места, требующие применения новых стратегий. Вы также можете использовать этот код для быстрого сравнения эффективности двух различных подходов, чтобы определить, какой из них лучше соответствует вашим запросам. Так, если для если для настройки пользовательского интерфейса и заполнения иерархического списка в элементе управления TreeView требуется три секунды, то вы можете захотеть изменить алгоритм таким образом, чтобы сначала заполнялись лишь узлы наивысшего уровня, а заполнение дочерних узлов откладывалось на более позднее время и осуществлялось лишь тогда, когда в этом возникнет действительная необходимость. Окончательное решение вы будете принимать на основании результатов соответствующих измерений и оценок качества приложения, предоставляемых конечными пользователями.