Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Анализ описанных выше шагов последовательной оптимизации
Обычно в тонкой настройке алгоритмов таятся значительные резервы. Самое важное при этом — это контролировать, обеспечивает ли выполнение настройки выигрыш в производительности, на который вы рассчитывали. Некоторыми своими "усовершенствованиями" вы можете непреднамеренно ухудшить производительность из-за того, что с ними связано распределение памяти, о котором вы можете не знать, или в силу каких-либо других причин. В процессе разработки приведенного выше кода у меня несколько раз возникали ситуации, когда я считал, что вносимые изменения должны улучшить результаты, но после проведения соответствующих измерений и при более глубоком рассмотрении оказывалось, что эти изменения приносили только вред. Всегда измеряйте показатели производительности и проводите их сравнительный
Кроме того, очень важно проводить тестирование на фактическом оборудовании, для которого предназначено ваше приложение, чтобы лучше почувствовать реальные условия работы с ним "на устройстве". Эмуляторы очень удобно использовать в процессе проектирования и базовой настройки приложения, но результаты, полученные на физическом устройстве, могут быть другими из-за различий в свойствах процессоров, памяти и других факторов. Одни программы могут выполняться на физических устройствах быстрее, другие — медленнее. Последнее слово всегда остается за фактическим оборудованием, которое будут использовать конечные пользователи. По тем же причинам очень важно измерять производительность при выполнении программы с подключенным отладчиком и без него. В некоторых случаях подключение отладчика резко снижает производительность.
Результаты тестирования трех различных алгоритмов, обсуждаемых нами, представлены в таблицах 8.1 и 8.2.
Таблица 8.1. Результаты тестирования алгоритмов (в секундах) на эмуляторе Pocket PC с вычислением 8000 циклов
| Порядковый номер теста | Неэкономное распределение памяти | Незначительное уменьшение объема распределяемой памяти | Значительное уменьшение объема распределяемой памяти |
|---|---|---|---|
| 1 | 12,65 | 12,2 | 8,925 |
| 2 | 12,775 | 12,35 | 8,55 |
| 3 | 12,575 | 12,25 | 8,225 |
| 4 | 12,625 | 12,525 | 8,575 |
| Среднее | 12,65625 | 12,33125 | 8,56875 |
| Экономия времени по сравнению с базовым уровнем | 0% | 2,57% | 32,30% |
Таблица 8.2. Результаты тестирования алгоритмов (в секундах) на физическом устройстве Pocket PC с вычислением 2000 циклов
| Порядковый номер теста | Неэкономное распределение памяти | Незначительное уменьшение объема распределяемой памяти | Значительное уменьшение объема распределяемой памяти |
|---|---|---|---|
| 1 | 30,609 | 30,151 | 20,484 |
| 2 | 30,538 | 30,016 | 20,362 |
| 3 | 30,517 | 30,195 | 20,377 |
| 4 | 30,457 | 30,316 | 20,429 |
| Среднее | 30,53025 | 30,1695 | 20,413 |
| Экономия времени по сравнению с базовым уровнем | 0% | 1,18% | 33,14% |
Анализ приведенных выше результатов говорит о следующем:
■ Применение первого варианта оптимизации, основанного на повторном использовании объектов вместо распределения памяти, обеспечило лишь самое минимальное повышение производительности. Вероятно, такое поведение приложения объясняется небольшими размерами самих объектов и используемых данных. Уже зная полученные результаты, можно отметить, что в них нет ничего удивительного. Учитывая легкость проведения этого вида оптимизации, который требует включения всего лишь нескольких новых строк кода, он заслуживает интереса. Дополнительным преимуществом этого способа, которое не отражают приведенные выше цифры, является то, что исключение размещения в памяти новых объектов из цикла с большим количеством повторений должно приводить к значительному уменьшению "объектного мусора" в нашем приложении.
■ Второй из проверенных нами вариантов оптимизации, заключающийся в отказе от распределения памяти для нескольких строковых объектов и использовании вместо этого строковых индексов, оказал на производительность приложения значительное воздействие. Благодаря внесению изменений в проект вспомогательного класса и задержке создания строкового класса до тех пор, пока это действительно не потребуется, мы непосредственно увеличили общую производительность алгоритма более чем на треть. Кроме того, как и в рассмотренном выше случае, нам удалось значительно уменьшить количество "мусора", образующегося в результате работы нашего алгоритма. Следствием этого явилось уменьшение общего объема "мусора", а также более ровное и быстрое выполнение приложения.
■ Закономерности изменения производительности в ряду вариантов оптимизации для эмулятора и физических устройств Pocket PC в основном совпадают, но между абсолютными показателями производительности алгоритма для этих двух случае наблюдаются разительные отличия. В нашем примере (распределение памяти для строк) результатом оптимизации явилось одинаковое улучшение производительности как на эмуляторе, так и на физических устройствах, но самый оптимальный вариант алгоритма выполнялся на эмуляторе со скоростью 934 итерации в секунду, а на физическом устройстве — 122 итерации в секунду. Таким образом, данный алгоритм выполняется на эмуляторе в 7,6 раз быстрее по сравнению с физическим устройством. Если этот алгоритм является критическим, и мы собираемся применять его ко многим тысячам единиц данных, то мы должны позаботиться об организации обратной связи с пользователями приложения на время проведения вычислений. В этой связи может потребоваться привлечение фоновых потоков выполнения для обработки данных или использование меньших объемов данных в каждый момент времени. Единственный способ получения реальных результатов оценки производительности — это выполнение приложения на реальных устройствах с использованием реальных объемов данных.
Уделяйте особое внимание тому, как используются строки в ваших алгоритмах
Чрезвычайная широта применения и необычайная полезность строк при создании программного обеспечения делают этот специальный тип данных уникальным. Часто строки представляют обычный текст, но нередко они используются и для передачи машинных данных, например строк запросов баз данных. Короче говоря, строки вездесущи, а байтовый тип данных применяется в большинстве приложений там, где надо, и там, где не надо. Современные языки программирования позволяют очень легко работать со строками, создавать их, разбивать, копировать и объединять. Рассмотрим, например, следующие простые операторы.
Каждый из этих операторов создает типы и размещает данные в памяти, и при этом нам даже не приходится вызывать никаких функций! Многие разработчики пользуются строками настолько бездумно, что легко могут допустить их некорректное использование. Не оптимизированная обработка строк является одной из наиболее вероятных причин плохой производительности. Ниже представлены некоторые рекомендации и правила, которыми следует руководствоваться при работе со строками. (При этом подразумевается, что вы работаете в .NET Framework/.NET Compact Framework, однако аналогичные правила будут действовать и в других средах. Более детальные разъяснения вы найдете в соответствующем справочном руководстве для своей среды.)
■ Строки неизменчивы (постоянны). Этот странный термин неизменчивый (immutable) просто означает, что текстовые данные строки не могут быть изменены в памяти. Те операции в коде, которые, как вам кажется, изменяют данные строки, на самом деле создают новую строку. Постоянство обладает некоторыми весьма привлекательными свойствами. Например, поскольку строковые данные сами по себе являются статическими, несколько переменных могут указывать на одни и те же данные; благодаря этому присвоение одной строковой переменной значения другой сводится к простому копированию "указателя" вместо глубокого копирования всех данных, которые ему соответствуют. Отрицательной стороной неизменчивости является невозможность изменения данных. Если вы хотите изменить, добавить или отсечь данные, то эти изменения будут отражаться в новой копии строки.