Таблица 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% |
Анализ приведенных выше результатов говорит о следующем:
■ Применение первого варианта оптимизации, основанного на повторном использовании объектов вместо распределения памяти, обеспечило лишь самое минимальное повышение производительности. Вероятно, такое поведение приложения объясняется небольшими размерами самих объектов и используемых данных. Уже зная полученные результаты, можно отметить, что в них нет ничего удивительного. Учитывая легкость проведения этого вида оптимизации, который требует включения всего лишь нескольких новых строк кода, он заслуживает интереса. Дополнительным преимуществом этого способа, которое не отражают приведенные выше цифры, является то, что исключение размещения в памяти новых объектов из цикла с большим количеством повторений должно приводить к значительному уменьшению "объектного мусора" в нашем приложении. В результате этого сборка мусора будет осуществляться реже, следствием чего должно быть значительное улучшение общей производительности. Этот вид оптимизации не привел к существенному повышению скорости выполнения приложения, но и не ухудшил ее, а, кроме того, обеспечил значительное уменьшение объема образующегося "мусора".
■ Второй из проверенных нами вариантов оптимизации, заключающийся в отказе от распределения памяти для нескольких строковых объектов и использовании вместо этого строковых индексов, оказал на производительность приложения значительное воздействие. Благодаря внесению изменений в проект вспомогательного класса и задержке создания строкового класса до тех пор, пока это действительно не потребуется, мы непосредственно увеличили общую производительность алгоритма более чем на треть. Кроме того, как и в рассмотренном выше случае, нам удалось значительно уменьшить количество "мусора", образующегося в результате работы нашего алгоритма. Следствием этого явилось уменьшение общего объема "мусора", а также более ровное и быстрое выполнение приложения.
