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

Таблица 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%

Анализ приведенных выше результатов говорит о следующем:

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

■ Второй из проверенных нами вариантов оптимизации, заключающийся в отказе от распределения памяти для нескольких строковых объектов и использовании вместо этого строковых индексов, оказал на производительность приложения значительное воздействие. Благодаря внесению изменений в проект вспомогательного класса и задержке создания строкового класса до тех пор, пока это действительно не потребуется, мы непосредственно увеличили общую производительность алгоритма более чем на треть. Кроме того, как и в рассмотренном выше случае, нам удалось значительно уменьшить количество "мусора", образующегося в результате работы нашего алгоритма. Следствием этого явилось уменьшение общего объема "мусора", а также более ровное и быстрое выполнение приложения.