Эффективность и оптимизация программ

Эффективными считаются программы, требующие минимального времени выполнения и/или минимального объема оперативной памяти. Особые требования к эффективности

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

существенному ухудшению технологических свойств, необходимо это требование иметь в виду [7].

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

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

Не следует забывать и о том, что многие способы снижения временных затрат приводят к увеличению емкостных и, наоборот, уменьшение объема памяти может потребовать

дополнительного времени на обработку.

И тем более не следует «платить» за увеличение эффективности снижением технологичности разрабатываемого программного обеспечения. Исключения возможны лишь при очень жестких требованиях и наличии соответствующего контроля за качеством.

Частично проблему эффективности программ решают за программиста компиляторы.

Средства оптимизации, используемые компиляторами, делят на две группы:

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

пересылок, использование более эффективных команд и т. п.

• машинно-независимые выполняют оптимизацию на уровне входного языка, например, вынесение вычислений константных (независящих от индекса цикла) выражений из

циклов и т. п.

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

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

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

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

Также следует помнить, что при передаче структурных данных в подпрограмму «по значению» копии этих данных размещаются в стеке. Избежать копирования иногда удается, если передавать данные «по ссылке», но как неизменяемые (описанные

const). В последнем случае в стеке размещается только адрес данных, например:

Type Mas.4iv array [I. 100] of real;

function Summa (Const a:Massiv; .)

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

программы с большим количеством повторений. При их написании необходимо по возможности:

• выносить вычисление константных, т. е. не зависящих от параметров цикла, выражений из циклов;

• избегать «длинных» операций умножения и деления, заменяя их сложением, вычитанием и сдвигами;

• минимизировать преобразования типов в выражениях;

• оптимизировать запись условных выражений — исключать лишние проверки;

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

• избегать использования различных типов в выражении и т. п.

Рассмотрим следующие примеры.

Пример 5.3. Пусть имеется цикл следующей структуры (Pascal):

for у: 0 to 99 do

for x: 0 to 99 do

а [320*х+у] S [k,l];

В этом цикле операции умножения и обращения к элементу S[k] выполняются 10 000 раз.

Оптимизируем цикл, используя, что 320 = 28 + 26:

ski: =S [k,l]; {выносим обращение к элементу массива из цикла}

for x: 0 to 99 do (меняем циклы местами}

begin

х shl 8 + х shl 6; {умножение заменяем на сдвиги и выносим из цикла)

for у; 0 to 99 do

a [i+y] =skl;

end;

В результате вместо 10 000 операций умножения будут выполняться 200 операций сдвига, а их время приблизительно сравнимо со временем выполнения операции сложения.

Обращение к элементу массива S[k] будет выполнено 1 раз.

Пример 5.4. Пусть имеется цикл, в теле которого реализовано сложное условие:

for k: 2 to n do

begin

ifx[k] > ук then S: S+y[k]-x [к];

if (x [k]< = yk) and (y[k]<yk) then S: = S+yk-x[k];

end;...

В этом цикле можно убрать лишние проверки:

for k: =2 to n do

begin

if x [k]>yk then S:=S+y[к]-х[к] else if y[k]<yk then S: =S+yk-x [k];

end;

Обратите внимание на то, что в примере 5.3 понять, что делает программа, стало сложнее, а в примере 5.4 — практически нет. Следовательно, оптимизация, выполненная в первом

случае, может ухудшить технологичность программы, а потому не очень желательна.

Урок 32.

Предмет: Технология разработки программных продуктов.

Тема: Метрики измерения программного продукта.

Цели:

Образовательная

Ознакомление с метриками измерения ПО.

Развивающая:

Развивать умение слушать других, делать выводы и обобщать полученные знания

Воспитательная:

Воспитывать чувство значимости предмета в профессиональной деятельности, аккуратности в работе

Межпредметные связи:

- Английский язык

- Операционные системы

- Информационные технологии

- Основы алгоритмизации и программирования

Оборудование: доска, мел, письменные принадлежности, проектор, ПК

Тип урока: комбинированный

Метод обучения: Объяснительно иллюстративный

Ход урока:

1.Организационный момент

- Проверка готовности кабинета

- Объявление темы

2. Постановка цели урока

3.Повторение пройденного материала

Эффективность и оптимизация программ

Способы экономии памяти.

Способы уменьшения времени выполнения.

Сопровождение программного продукта

Отладка программного продукта

4.Сообщение новых знаний

1. Основные понятия
2. Измерения, меры и метрики.
3. Размерно-ориентированные метрики
4. Функционально-ориентированные метрики
5. Выполнение оценки проекта на основе LOC- и FP-метрик
6. Метрики объектно-ориентированных программных систем
7. Набор метрик Чидамбера и Кемерера
8. Метрики Лоренца и Кидда

5. Восприятие и осознание учащимися нового материала

6. Осмысление обобщение и систематизация знаний

7. Подведение итогов урока и постановка домашнего задания

Выучить содержимое темы

Орлов С.А. стр.189-209

Ответить на вопросы:

1.Основные понятия

Ме́трика програ́ммного обеспе́чения (англ. software metric) — это мера, позволяющая получить численное значение некоторого свойства программного обеспечения илиего спецификаций.

Поскольку количественные методы хорошо зарекомендовали себя в других областях, многие теоретики и практики информатики пытались перенести данный подход и вразработку программного обеспечения. Как сказал Том ДеМарко, «вы не можете контролировать то, что не можете измерить».

Набор используемых метрик включает:

• порядок роста (имеется в виду анализ алгоритмов в терминах асимптотического анализа и O-нотации),
• количество строк кода,
• цикломатическая сложность,
• анализ функциональных точек,
• количество ошибок на 1000 строк кода,
• степень покрытия кода тестированием,
• покрытие требований,
• количество классов и интерфейсов,
• метрики программного пакета от Роберта Сесиль Мартина,
• связность.

Цикломати́ческая сло́жность програ́ммы (англ. Cyclomatic complexity of a program) — структурная (или топологическая) мера сложности программ, используемая для измерения качества программного обеспечения, основанная на методах статического анализа кода.

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

Техника покрытия кода была одной из первых методик, изобретённых для систематического тестирования ПО. Первое упоминание покрытия кода в публикациях появилось в 1963 году.

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

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

Связность или сцепление (англ. cohesion) — характеристика внутренней взаимосвязи между частями одного модуля (сравни со связанностью).

Потенциальные недостатки подхода, на которые нацелена критика:

• Неэтичность: Утверждается, что неэтично сводить оценку работы человека к нескольким числовым параметрам и по ним судить о производительности. Менеджер может назначить наиболее талантливых программистов на сложнейший участок работы; это означает, что разработка этого участка займёт наибольшее время и породит наибольшее количество ошибок, из-за сложности задачи. Не зная об этих трудностях, другой менеджер по полученным показателям может решить, что программист сделал свою работу плохо.
• Замещение «управления людьми» на «управление цифрами», которое не учитывает опыт сотрудников и их другие качества
• Искажение: Процесс измерения может быть искажён за счёт того, что сотрудники знают об измеряемых показателях и стремятся оптимизировать эти показатели, а не свою работу. Например, если количество строк исходного кода является важным показателем, то программисты будут стремиться писать как можно больше строк и не будут использовать способы упрощения кода, сокращающие количество строк.
• Неточность:Нет метрик, которые были бы одновременно и значимы и достаточно точны. Количество строк кода — это просто количество строк, этот показатель не даёт представление о сложности решаемой проблемы. Анализ функциональных точек был разработан с целью лучшего измерения сложности кода и спецификации, но он использует личные оценки измеряющего, поэтому разные люди получат разные результаты.

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