412 000 произведений, 108 200 авторов.

Электронная библиотека книг » Иво Салмре » Программирование мобильных устройств на платформе .NET Compact Framework » Текст книги (страница 25)
Программирование мобильных устройств на платформе .NET Compact Framework
  • Текст добавлен: 18 июля 2025, 02:31

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


Автор книги: Иво Салмре



сообщить о нарушении

Текущая страница: 25 (всего у книги 69 страниц)

Анализ описанных выше шагов последовательной оптимизации

Обычно в тонкой настройке алгоритмов таятся значительные резервы. Самое важное при этом – это контролировать, обеспечивает ли выполнение настройки выигрыш в производительности, на который вы рассчитывали. Некоторыми своими "усовершенствованиями" вы можете непреднамеренно ухудшить производительность из-за того, что с ними связано распределение памяти, о котором вы можете не знать, или в силу каких-либо других причин. В процессе разработки приведенного выше кода у меня несколько раз возникали ситуации, когда я считал, что вносимые изменения должны улучшить результаты, но после проведения соответствующих измерений и при более глубоком рассмотрении оказывалось, что эти изменения приносили только вред. Всегда измеряйте показатели производительности и проводите их сравнительный анализ для различных вариантов реализации!

Кроме того, очень важно проводить тестирование на фактическом оборудовании, для которого предназначено ваше приложение, чтобы лучше почувствовать реальные условия работы с ним "на устройстве". Эмуляторы очень удобно использовать в процессе проектирования и базовой настройки приложения, но результаты, полученные на физическом устройстве, могут быть другими из-за различий в свойствах процессоров, памяти и других факторов. Одни программы могут выполняться на физических устройствах быстрее, другие – медленнее. Последнее слово всегда остается за фактическим оборудованием, которое будут использовать конечные пользователи. По тем же причинам очень важно измерять производительность при выполнении программы с подключенным отладчиком и без него. В некоторых случаях подключение отладчика резко снижает производительность.

Результаты тестирования трех различных алгоритмов, обсуждаемых нами, представлены в таблицах 8.1 и 8.2.

Таблица 8.1. Результаты тестирования алгоритмов (в секундах) на эмуляторе Pocket PC с вычислением 8000 циклов


112,6512,28,925
212,77512,358,55
312,57512,258,225
412,62512,5258,575
Среднее12,6562512,331258,56875
Экономия времени по сравнению с базовым уровнем0%2,57%32,30%

Таблица 8.2. Результаты тестирования алгоритмов (в секундах) на физическом устройстве Pocket PC с вычислением 2000 циклов


130,60930,15120,484
230,53830,01620,362
330,51730,19520,377
430,45730,31620,429
Среднее30,5302530,169520,413
Экономия времени по сравнению с базовым уровнем0%1,18%33,14%

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

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

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

■ Закономерности изменения производительности в ряду вариантов оптимизации для эмулятора и физических устройств Pocket PC в основном совпадают, но между абсолютными показателями производительности алгоритма для этих двух случае наблюдаются разительные отличия. В нашем примере (распределение памяти для строк) результатом оптимизации явилось одинаковое улучшение производительности как на эмуляторе, так и на физических устройствах, но самый оптимальный вариант алгоритма выполнялся на эмуляторе со скоростью 934 итерации в секунду, а на физическом устройстве – 122 итерации в секунду. Таким образом, данный алгоритм выполняется на эмуляторе в 7,6 раз быстрее по сравнению с физическим устройством. Если этот алгоритм является критическим, и мы собираемся применять его ко многим тысячам единиц данных, то мы должны позаботиться об организации обратной связи с пользователями приложения на время проведения вычислений. В этой связи может потребоваться привлечение фоновых потоков выполнения для обработки данных или использование меньших объемов данных в каждый момент времени. Единственный способ получения реальных результатов оценки производительности – это выполнение приложения на реальных устройствах с использованием реальных объемов данных.

Уделяйте особое внимание тому, как используются строки в ваших алгоритмах

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

string str1 = "foo"; //Размещает в памяти строковый объект

string str2 = "bar"; //Размещает в памяти строковый объект

string str3 = str1 + str2; //Размещает в памяти строковый объект

string str3 = str3 + str3; //Размещает в памяти строковый объект

Каждый из этих операторов создает типы и размещает данные в памяти, и при этом нам даже не приходится вызывать никаких функций! Многие разработчики пользуются строками настолько бездумно, что легко могут допустить их некорректное использование. Не оптимизированная обработка строк является одной из наиболее вероятных причин плохой производительности. Ниже представлены некоторые рекомендации и правила, которыми следует руководствоваться при работе со строками. (При этом подразумевается, что вы работаете в .NET Framework/.NET Compact Framework, однако аналогичные правила будут действовать и в других средах. Более детальные разъяснения вы найдете в соответствующем справочном руководстве для своей среды.)

Строки неизменчивы (постоянны). Этот странный термин неизменчивый (immutable) просто означает, что текстовые данные строки не могут быть изменены в памяти. Те операции в коде, которые, как вам кажется, изменяют данные строки, на самом деле создают новую строку. Постоянство обладает некоторыми весьма привлекательными свойствами. Например, поскольку строковые данные сами по себе являются статическими, несколько переменных могут указывать на одни и те же данные; благодаря этому присвоение одной строковой переменной значения другой сводится к простому копированию "указателя" вместо глубокого копирования всех данных, которые ему соответствуют. Отрицательной стороной неизменчивости является невозможность изменения данных. Если вы хотите изменить, добавить или отсечь данные, то эти изменения будут отражаться в новой копии строки.

Когда на строковые данные не ссылается ни одна "активная" ("live") переменная, они становятся "мусором". Рассмотрим пример:

string str1 = "foo"; //"foo" – статические данные, скомпилированные

                     //в двоичные данные вашего приложения

string str2 = str1 + str1; //только что была создана новая строка, явля-

                           //ющаяся результатом конкатенации двух строк

str2 = "bar"; //Поскольку отсутствуют другие переменные, указываю-

              //щие на те данные, на которые указывала переменная str2,

              //эти данные становятся мусором, и память должна быть

              //очищена от них.

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

Если вы создаете новые строки внутри циклов, настоятельно рекомендуется рассмотреть возможность использования объекта StringBuilder. Все виды строк создаются на основе других переменных, обрабатываемых в циклах. Типичным примером динамического создания строк может служить цикл, генерирующий текстовый отчет, каждая строка которого содержит следующие данные:

//Неэффективный код, выполняющийся внутри цикла...

{

 myString = myString +"CustomerID: " +

  System.Convert.ToString(customer[idx].id) +

  ", Name: " + System.Convert.ToString(customer[idx].name);

}

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

■ Измеряйте объективные количественные показатели своих алгоритмов. Занимаясь написанием алгоритма обработки строк, тестируйте его быстродействие! Испробуйте несколько различных подходов. Вы очень быстро научитесь распознавать, какой алгоритм будет эффективным, а какой – нет.

Пример эффективного создания строк

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

Листинг 8.9. Сравнение эффективности использования строк и класса StringBuilder в алгоритмах

Примечание. В этом примере используется класс PerformanceSampling, определенный ранее в данной книге.

const int COUNT_UNTIL = 300;

const int LOOP_ITERATIONS = 40;

//–

//HE ОЧЕНЬ ЭФФЕКТИВНЫЙ АЛГОРИТМ!

//

//Для имитации создания типичного набора строк используются

//обычные строки

//–

private void button1_Click(object sender, System.EventArgs e) {

 //Вызвать сборщик мусора, чтобы тест //начинался с чистого состояния.

 //ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

 //сборщика мусора в программах вручную будут приводить

 //к снижению общей производительности приложений!

 System.GC.Collect();

 int numberToStore = 0;

 PerformanceSampling.StartSample(0, "StringAllocaitons");

 string total_result = "";

 for (int outer_loop = 0; outer loop < LOOP_ITERATIONS; outer_loop++) {

  //Сбросить старый результат total_result = "";

  //Выполнять цикл до максимального значения x_counter, каждый

  //раз присоединяя очередную тестовую строку к рабочей строке

  for (int x_counter = 0; x_counter < COUNT_UNTIL; x_counter++) {

   total_result = total_result + numberToStore.ToString() + ", ";

   //Увеличить значение счетчика

   numberToStore ++;

  }

 }

 PerformanceSampling.StopSample(0); //Отобразить длину строки

 System.Windows.Forms.MessageBox.Show("Длина строки: " + total_result.Length.ToString());

 //Отобразить строку

 System.Windows.Forms.MessageBox.Show("Строка : " + total_result);

 //Отобразить длительность интервала времени, ушедшего на вычисления

 System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(0));

}

//–

//ГОРАЗДО БОЛЕЕ ЭФФЕКТИВНЫЙ АЛГОРИТМ!

//

//Для имитации создания типичного набора строк используется

//объект StringBuilder

//–

private void button2_Click(object sender, System.EventArgs e) {

 //Вызвать сборщик мусора, чтобы тест

 //начинался с чистого состояния.

 //ПРИБЕГАЙТЕ К ЭТОЙ МЕРЕ ТОЛЬКО В ЦЕЛЯХ ТЕСТИРОВАНИЯ! Вызовы

 //сборщика мусора в программах вручную будут приводить

 //к снижению общей производительности приложений!

 System.GC.Collect();

 System.Text.StringBuilder sb = new System.Text.StringBuilder();

 string total_result = "";

 int numberToStore = 0;

 PerformanceSampling.StartSample(1, "StringBuilder");

 for (int outer_loop = 0; outer_loop < LOOP_ITERATIONS; outer_loop++) {

  //Очистить объект StringBuilder (не создавая нового объекта)

  sb.Length = 0;

  //Очистить строку со старым результатом

  total_result = "";

  //Выполнять цикл до максимального значения x_counter, каждый раз

  //присоединяя очередную тестовую строку к рабочей строке

  for (int x_counter = 0; x_counter < COUNT_UNTIL; x_counter++) {

   sb.Append(numberToStore);

   sb.Append(", ");

   //Увеличить значение счетчика

   numberToStore++;

  }

  //Имитируем выполнение некоторых операций над строкой...

  total_result = sb.ToString();

 }

 PerformanceSampling.StopSample(1);

 //Отобразить длину строки

 System.Windows.Forms.MessageBox.Show("Длина строки: " + total_result.Length.ToString());

 //Отобразить строку

 System.Windows.Forms.MessageBox.Show("String : " + total_result);

 //Отобразить длительность интервала времени, ушедшего на вычисления

 System.Windows.Forms.MessageBox.Show(PerformanceSampling.GetSampleDurationText(1));

}

Таблица 8.3. Сравнение результатов (в секундах) для 40×300 циклов, выполненных с использованием эмулятора


125,4750,85
225,2250,925
324,50,875
Среднее25,070.88
Экономия времени по сравнению с базовым уровнем0%96,5%

Таблица 8.4. Сравнение результатов (в секундах) для 40×300 циклов, выполненных на физическом устройстве Pocket PC


122,5026,257
222,346,346
322,3786,35
Среднее22,416,32
Экономия времени по сравнению с базовым уровнем0%71,8%

Ниже представлен анализ полученных результатов.

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

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

В некоторых случаях результаты оптимизации для физического мобильного устройства могут превосходить результаты для эмулятора, выполняющегося на гораздо более мощной машине. В рассмотренном выше примере, в котором память распределялась для строк, прирост производительности в результате полной оптимизации для физического устройства Pocket PC был больше, чем в случае выполнения эмулятора на моем лэптопе. Однако при использовании объектов StringBuilder наблюдается обратная ситуация. В отношении абсолютной производительности метод использование объектов StringBuilder демонстрирует явное превосходство над методом, использующим распределение памяти для строк. В качестве грубого ориентира при сопоставлении алгоритмов можно руководствоваться тем, что тот алгоритм, который на эмуляторе, установленном на персональном компьютере, выполняется быстрее, окажется более быстрым и на мобильном устройстве; в то же время, если требуется более точная оценка, целесообразно всегда проводить тестирование производительности на физическом мобильном оборудовании.

Резюме

Разрабатывая схему управления памятью в приложении, важно анализировать, что происходит как на "макроскопическом" уровне приложения, так и на "микроскопическом" уровне алгоритма. Нa макроскопическом уровне важно иметь модель памяти, которая обеспечивает экономное потребление памяти устройства, но при этом позволяет вам держать под рукой данные и ресурсы, которые в вашем приложении используются наиболее часто. При решении этой задачи для ресурсов приложения вам может очень пригодиться подход, основанный на использовании конечного автомата. Что касается пользовательских данных приложения, то в этом случае целесообразно создать класс, предназначенный для управления объемом данных приложения, которые должны храниться в памяти в каждый момент времени. Этот класс будет играть роль инкапсулированного конечного автомата, которому известно, каким образом воспользоваться новыми данными, когда в этом возникает необходимость, или избавиться от устаревших данных, которые только напрасно занимают память. Обязательно вызывайте метод Dispose(), когда заканчиваете работу с объектами, для которых он предусмотрен; эта мера обеспечит принудительное освобождение неуправляемых ресурсов, удерживаемых объектом, и увеличит общую пропускную способность системы.

На уровне алгоритма важно не только выбрать наиболее подходящий алгоритм обработки данных, но и эффективно реализовать его. При реализации алгоритма вы должны стремиться к тому, чтобы объем памяти, распределяемой для объектов, был как можно меньшим; для кода, выполняющегося в цикле, это приобретает еще большее значение. Особого внимания заслуживают строки, чрезвычайная широта применения которых повышает вероятность того, что часть памяти, связанная с распределением и освобождением строк, будет расходоваться понапрасну. В случае строковых алгоритмов наибольший интерес представляют два подхода: 1) использование индексов для ссылки на содержащиеся в строке данные, а не извлечение подстрок в виде отдельных строк, и 2) создание строк с помощью класса StringBuilder (или его эквивалентов в случае других сред выполнения). В процессе написания своих алгоритмов проявляйте особую осмотрительность при создании и освобождении объектов, поскольку распределение памяти для объектов и их инициализация требуют определенного времени, а объекты в конечном счете превращаются в "мусор", от которого среда выполнения должна избавляться. Создание мусора означает необходимость выполнения лишней работы по очистке системы от него, что снижает общую производительность приложения. Концепция объектов необычайно плодотворна, однако их неправильное использование влечет за собой дополнительные накладные расходы; в процессе проектирования алгоритмов эти соображения необходимо всегда учитывать.

Среда выполнения вашего мобильного приложения во многом может быть уподоблена небольшой квартире– Пока такая квартира не слишком забита вещами, проживание в ней может доставлять одно удовольствие. Стоит, однако, вещам загромоздить ее, как вам станет трудно перемещаться по ней и вообще что-либо делать. Если в процессе вашей ежедневной деятельности создается много мусора, то вам приходится часто выносить мусорное ведро и тратить время на наведение порядка вместо того, чтобы заниматься полезной работой. На макроуровне в обыденной жизни следует стремиться к тому, чтобы жилье было опрятным и просторным, а все необходимые вещи были всегда под рукой. Что касается микроуровня, то следует просто не мусорить!


    Ваша оценка произведения:

Популярные книги за неделю