Как оптимизировать код программы

Здесь приведен перевод апноута Atmel «AVR4027: Tips and Tricks to Optimize Your C Code for 8-bit AVR Microcontrollers» [1]. Затронуты следующие темы:

• Ядро Atmel® AVR® и ознакомление с Atmel AVR GCC
• Советы по уменьшению размера кода
• Советы по уменьшению времени выполнения
• Примеры программ

[Введение]

Ядро AVR построено на продвинутой технологии RISC, и оно оптимизировано под кодирование на языке C. Это обеспечивает хорошее качество разработки с получением большего количества возможностей за меньшую цену. Прим. переводчика: на самом деле, если сравнивать с архитектурой MCS51, в плане объема кода у AVR не все так хорошо. Места под код уходит гораздо больше, потому что большинство команд ассемблера AVR занимают как минимум 2 байта.

Когда идет речь об оптимизации, то обычно имеют в виду два аспекта: объем кода (size optimization) и скорость работы кода (speed optimization). В настоящее время компиляторы C имеют различные опции оптимизации, чтобы помочь разработчикам получить эффективный код либо по размеру, либо по скорости ( прим. переводчика: на самом деле чаще всего используется оптимизация по размеру -Os, так как эта оптимизация также позволяет получить и более быстрый код по сравнению с отключенной оптимизацией ).

Вся суть чистого кода

Однако хорошее кодирование на C дает компилятору больше возможностей оптимизировать код, что почти всегда необходимо разработчику. В некоторых случаях оптимизация по одному из аспектов приводит к деградации параметров по другому аспекту, так что разработчик выбирает компромисс для сбалансированного согласования размера кода и скорости выполнения — в зависимости от конкретных условий и техзадания. Понимание некоторых принципов и следование определенным советам в кодировании на языке C для 8-bit AVR помогает разработчику правильно фокусироваться на улучшении эффективности кода в нужном направлении.

В этом апноуте советы базируются на использовании avr-gcc (компилятор C). Однако рассмотренные принципы могут быть использованы и для других компиляторов с соответствующими опциями.

[2 Знания ядра Atmel AVR и Atmel AVR GCC]

Перед оптимизированием программного обеспечения для встраиваемых систем (firmware) необходимо иметь хорошее понимание следующего: какую структуру имеет ядро AVR, и какие стратегии использует AVR GCC для генерирования эффективного кода для этого процессора ( прим. переводчика: обычно проприетарные платные компиляторы, например от IAR, позволяют получать гораздо более эффективный код ). Здесь приведена короткая сводка возможностей ядра AVR и AVR GCC.

2. 8-битная архитектура Atmel AVR

AVR использует Гарвардскую архитектуру ядра – с раздельным адресным пространством памяти и раздельными шинами для памяти программ (FLASH) и памяти данных (SRAM). AVR имеет регистровый файл 32×8 с быстрым доступом, используемые как рабочие регистры с временем доступа за 1 тактовый цикл. Использование 32 рабочих регистров является ключом к эффективному кодированию на C. Эти регистры имеют тот же функционал, что и традиционный аккумулятор, за исключением того, что их количество 32 штуки. Арифметика AVR и инструкции логики работают для этих регистров, следовательно код может занимать меньше места. За один такт AVR может предоставить два любых регистра для ALU, выполнить нужную операцию, и записать результат обратно в регистровый файл.

Уроки С++. Изучай и оптимизируй! Советы С++. Оптимизация цикла!

Инструкции в памяти программ выполняются в конвейеризацией на одном уровне. Когда выполняется одна инструкция, следующая инструкция предварительно выбирается из памяти программ. Эта концепция дает возможность выполнять по одной инструкции на каждый такт. Большинство инструкций AVR имеют формат одного 16-битного слова. Каждый адрес памяти программ содержит 16- или 32-битную инструкцию.

Пожалуйста обратитесь к секции “AVR CPU Core” даташита для получения дополнительной информации.

2.2 AVR GCC

GCC означает GNU Compiler Collection (коллекция компилятора GNU). Когда GCC используется для цели AVR, он обычно известен как AVR GCC. Действительный исполняемый файл компилятора имеет префикс «avr-«, в результате получается «avr-gcc».

AVR GCC предоставляет несколько уровней оптимизации. Это -O0, -O1, -O2, -O3 и -Os. На каждом уровне разрешаются разные опции оптимизации, за исключением опции -O0, которая означает отсутствие оптимизации. Помимо вариантов, рассортированных по уровням оптимизации, Вы можете использовать разные опции оптимизации для получение специфичной оптимизации. Пожалуйста обратитесь к руководству GNU Compiler Collection [3] для получения полного списка опций и уровней оптимизации.

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

Помимо «avr-gcc» требуется много дополнительных инструментов для получения конечного исполняемого кода firmware для микроконтроллера AVR. Сгруппированный набор этих инструментов называется тулчейном (toolchain). В этом AVR тулчейне avr-libc служит важной библиотекой кода C, предоставляющей многие те же самые функции, которые можно найти в обычной стандартной библиотеке C и многие дополнительные библиотечные функции, специфичные для AVR.

Пакет AVR Libc предоставляет подмножество функций стандартной библиотеки C для микроконтроллеров Atmel AVR 8-bit RISC. Дополнительно библиотека предоставляет базовый код запуска (startup code), который нужен для большинства приложений. См. руководство avr-libc [4].

Прим. переводчика: когда Вы ищите ошибки в программе и отлаживаете её, то обязательно опробуйте все варианты оптимизации по скорости и размеру кода. Во всех выбранных вариантах оптимизации — в том числе и с отключенной оптимизацией — код должен работать всегда одинаково и надежно, и его работоспособность не должна теряться. Если программа в каком-то варианте не работает, то значит либо код имеет необнаруженную ошибку, либо написан неоптимально, либо есть узкое место. Управление оптимизацией [8] — хорошее средство для тестирования качества кода, не забывайте о нем!

2.3 Платформа разработки

Примеры кода и результаты тестирования этого документа базируются на следующих условиях:

1. Интегрированная система разработки (Integrated Development Environment, IDE): Atmel AVR Studio® 5 (Version: 5.0.1119).
2. AVR GCC 8-bit Toolchain Version: AVR_8_bit_GNU_Toolchain_3.2.1_292 (gcc version 4.5.1).
3. Целевой микроконтроллер AVR (Target Device): Atmel ATmega88PA.

[3 Способы уменьшения размера кода]

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

3.1 Подсказка #1 – типы и размеры данных

Используйте всегда самые маленькие по размеру данные, насколько это возможно. Оцените свой код на используемые в нем типы данных. Чтение 8-битного значения из регистра требует только однобайтовой переменной, и ни в коем случае не двухбайтовой, это позволит экономить место под код. Размеры типов данных для 8-бит AVR можно найти в хедере < stdint.h >, и они перечислены в таблице 3-1.

Таблица 3-1. Типы данных 8-бит AVR.

Тип данных		Размер
signed char / unsigned char	int8_t / uint8_t	8 бит
signed int / unsigned int	int16_t / uint16_t	16 бит
signed long / unsigned long	int32_t / uint32_t	32 бита
signed long long / unsigned long long	int64_t / uint64_t	64 бита

Избегайте некоторых опций компилятора, которые могут изменить эту таблицу (например, avr-gcc -mint8 приводит тип int к 8-битному целому).

В таблице 3-2 показаны примеры использования типов данных разного размера. Использовалась оптимизация по размеру -Os. Вывод от утилиты avr-size дает возможность оценить размер кода.

Таблица 3-2. Пример использования типов данных разного размера.

#include < avr/io.h >
unsigned int readADC() < return ADCH; >;
int main(void) < unsigned int mAdc = readADC(); >

Источник: microsin.net

10 слов об оптимизации кода

Немного о грустном: вся наша жизнь – это борьба с тормозами. И вечно так продолжаться не может. Необходимо оптимизировать всё – начиная от своего рабочего места до времени. В этой статье я привёл примеры оптимизации кода на языке программирования Delphi, но поверь, эти советы могут пригодиться тебе и в реальной жизни, если подумать.

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

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

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

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

Это связано с тем, что все числа хранятся в двоичной системе. Если перевести число из десятичной системы счисления в двоичную и сдвинуть число вправо на одну позицию, то можно заметить, что данная операция аналогична делению на 2. При сдвиге влево происходит деление числа на 2. Хоть эти операции и аналогичны, но сдвиг работает в несколько раз быстрее.

5. При создании процедур не надо обременять их большим количеством входных параметров. А всё потому, что при каждом вызове процедуры её параметры подымаются в специальную область памяти, стек, а после выхода изымаются оттуда. Также необходимо действовать аккуратно и с самими параметрами. Не надо пересылать процедурам переменные, содержащие данные большого объёма в чистом виде. Лучше передать адрес ячейки памяти, где хранятся данные, а внутри процедуры уже работать с этим адресом.

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

7. Лишних проверок не бывает. Не надо думать, что если у вас не возникла какая-то нестандартная ситуация, то она не возникнет и у пользователя. Всегда делайте проверку того, что вводит пользователь, не дожидаясь, когда эти данные понадобятся.

8. Если ты пишешь достаточно большую и громоздкую программу, добавляй в неё комментарии. Компилятор их всё равно игнорирует. И если вдруг тебе захочется продать исходные коды своих программ, комментарии повысят им цену, да и самому будет легче в них ориентироваться.

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

10. Старайся делать в программах стандартный интерфейс. Ну не надо делать треугольные кнопочки, нестандартные меню и прочие графические навороты. Всё это очень сильно тормозит программу, расходует большое количество ресурсов компьютера и требует дополнительного времени на разработку. К примеру, настоящий UNIX – это вообще обычный shell – строка для ввода команд.

Вот вроде и всё. Желаю, удачи в написании своих программ, просто следуй этим советам, и всё у тебя получиться.

Источник: xakep.ru

Методика оптимизации программного кода 1С: проведение документов [1131]

Публикация предназначена в первую очередь для программистов, ведущих разработку ПО в крупных информационных системах с массивным потоком обрабатываемой информации и большим количеством пользователей. Я изучаю вопросы оптимизации более 15 лет, за это время участвовал и руководил проектами оптимизации информационных систем на базе различных конфигураций 1С практически во всех областях учета. На мой взгляд, первопричина зависаний и плохой работы программы 1С — некачественный программный код модулей конфигурации этой самой 1С. Если у вас проблемы с производительностью системы, вы можете устанавливать супер современное оборудование, тратить месяцы на обучение продвинутых пользователей, пробовать любые тонкие настройки ИТ-техники — без оптимизации программного кода, рано или поздно, вы сталкнетесь с теми же проблемами производительности, а зачастую с более серьезными.

Поэтому данная статья посвящена исключительно программной оптимизации.

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

Во-первых, давайте определимся, что же такое качественный код. Предлагаю очень простое и понятное определение правильного программного кода: «Нечего добавить и нечего убрать» Т.е. если при взгляде на код модуля вы понимаете, что ни один логический блок нельзя убрать или заменить более оптимальной структурой, не испортив требуемого функционала — будем считать, что это лучшая реализация из возможных, код качественный и работа по его улучшению завершена.
Во-вторых, при оценке программного кода необходимо руководствоваться здравым смыслом и не рассматривать его исключительно через призму рекомендаций 1С. В крупных информационных системах действуют свои законы и правила работы с данными. Очень часто, следуя рекомендациям 1С, мы достигаем противоположного эффекта. Для примера — использование временных таблиц. Из личного опыта: в 90% случаев причина зависаний и отказов 1С в клиент-серверном режиме — бездумное и необоснованное использование команды «Поместить» при построении запросов к базе данных.
В рамках этой публикации хочу остановиться на одном из самых узких мест с точки зрения производительности — обработке записи/проведения документов. Ниже представлена многократно проверенная методика оптимизации модулей проведения. Описанные методы и объекты помещены в небольшую конфигурацию, выгрузка демонстрационной базы во вложении.
Используемые в публикации скриншоты созданы из вложенной демонстрационной базы.

Подготовка конфигурации к оптимизации кода.

• справочник «Дополнительные константы» для хранения настроек;
• общий модуль «МодульОптимизация» с сервисными функциями и процедурами;
• параметр сеанса «ВклОптимизации» для переключения режима использования модулей (Исходных/оптимизированных). Добавляем в модуль сеанса его инициализацию;
• регистр «ОтложенноеПроведениеДокументов» для формирования очереди отложенного проведения документов. Используется для исключения конфликтов блокировок.
• обработка «Регламент» для запуска регламентных заданий (демонстрация отложенного проведения).
• обработка «ТестПроведения» для анализа результатов оптимизации.
• обработка «ТестоваяНагрузка» для дополнительной нагрузки системы во время теста.

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

Определение проблемных зон кода

1. Информацию о проблемах при проведении получаем от наших пользователей — они предоставляют ее в избытке.
2. Выбираем объект, работа которого наиболее критична для бизнеса.
3. В конфигураторе открываем модуль формы обработки «ТестПроведения».
4. Устанавливаем точки останова в процедуре «ВыполнитьТест» до и после основного цикла тестового проведения (в исходной обработке для обычных форм №стр 341 и 444).

• Открываем в сессии отладки обработку «ВыполнитьТест».
• Выбираем из списка выбора вид тестируемого документа.
• Устанавливаем количество тестовых проведений. Параметр используется для получения более точных средних показателей.
• Выбираем способ отбора тестируемых объектов: проведение выбранного документа или проведение выборки за период.
• Выполняем команду «Выполнить тестирование».

Выбор вида тестируемого документа

Выбор способа отбора тестируемых объектов

Запуск тестирования

6. При остановке на первой точке останова включаем режим замера производительности

Включение замера производительности

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

Участки кода с максимальными временными затратами

8. Продолжаем отладку. После завершения теста в окне сообщений отобразится результат замеров с временными показателями. Собственно уменьшение этих показателей и является нашей целью.

Результат тестирования

Анализ и исправление проблемных зон программного кода

• многократное выполнение одинаковых запросов к БД( к примеру, в цикле), с пониманием того, что получение через точку свойств ссылочных объектов, это так же запросы к БД;
• использование в тексте запросов инструкции «Поместить». Если есть возможность построить качественный запрос без использования временных таблиц, обязательно используйте эту возможность. Темповая база — это самое узкое место в массивных информационных системах. Проведение через нее потоков данных должно быть серьезно обосновано.
• уровень использования принудительного кеширования для значений, часто используемых в коде (к примеру, ссылок на организацию, статью движения, номенклатуру и пр.). Методов кеширования множество — хранение этих значений в локальных или глобальных переменных типа таблица или структура, подключение функций общих модулей с повторным использованием значений и пр.

Проблемный участок кода

2. Если найден сомнительный код и появились идеи по его исправлению, добавляем в общий модуль «МодульОптимизация» копию найденой процедуры(функции) с именем, содержащим префикс . Объукт документа передаем в параметре.
3. Оптимизируем код в новой процедуре(функции).

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

4. Добавляем в начало исходной процедуры(функции) переключение по значениям параметра сеанса на новую процедуру(функцию).
5. Повторяем алгоритм, описанный в п.II, но перед запуском команды «Выполнить тестирование» меняем настройки режима тестирования: устанавливаем флаги «Автоматическое тестирование кода до/после оптимизации» и «Сверка проводок, сформированных до и после включения режима оптимизации».

Включение режима сверки

6. После завершения теста в окне сообщений отобразится результат ваших стараний — показатели до и после использования оптимизированного кода.

Вывод результата оптимизации и сверки проводок

7. Выполняем алгоритмы II и III до тех пор, пока не будут ликвидированы критические проблемы производительности.
8. Если достичь желаемого результата не удается и проведение все равно занимает неприемлемо много времени, перенесите функционал проведения на сервер , используя алгоритм отложенного проведения. Упрощенная схема подобного алгоритма реализована в приложенной демонстрационной базе.

Описание настроек обработки «ТестПроведения»

• «Количество тестовых попыток записи/проведения документов» определяет количество перепроведений выбранного документа в режиме темта по 1 документу. В режиме теста по выборке за период параметр определяет количество отбираемых документов. Особенность теста по выборке — при повторном тестировании при формировании выборки исключаются документы, участвовавшие в предыдущих тестах.
• Флаг «Оптимизация включена для текущего пользователя» включает режим использования оптимизированных модулей для текещего пользователя.
• Флаг «Оптимизация включена для всех пользователей» включает режим использования оптимизированных модулей для всех пользователей.
• Флаг «Автоматическое тестирование кода до/после оптимизации» включает режим тестирования с автоматическим переключением использования оптимизированных модулей. При этом объекты теста перепроводятся дважды: с использованием исходного кода и с использованием оптимизированных модулей;
• Флаг «Сверка проводок, сформированных до и после включения режима оптимизации» включает режим сверки проводок документа, сформированных оптимизированным и не оптимизированным кодом;
• Флаг «Перезаписывать только проведенные» — для тестирования будут отбираться только проведенные документы;
• Флаг «Режим записи без проведения» — при тестировании документы будут записываться без проведения;
• Флаг «Автозапуск нагрузочных сессий» — перед началом тестирования будут запущены нагрузочные сессии 1С. После окончания теста нагрузочные сессии будут автоматически закрыты;
• «Каталог сохранения лога тестирования» определяет путь к каталогу, в котором автоматически сохранится результат теста;
• Команда «Выполнить тестовое проведение всех документов периода» запускает пакетное перепроведение всех документов выбранного периода. При этом документы перепроводятся партиями по 10, поочередно и в обычном режиме и в режиме оптимизации. Команда предназначена для анализа разультата оптимизации и сверки проводок в потоке.
• Флаг «Выполнить тест процедуры» — при тестировании будет выполнятся только код указанной процедуры;

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

Запуск режима оптимизации в рабочей базе

Перед включением режима оптимизации для всех пользователей рабочей базы рекомендую включить оптимизацию для 1-2х пользователей, которые особенно нагружены и недовольны зависаниями и сбоями. Во-первых это даст объективную оценку результата, во-вторых — это дополнительный пользовательский тест алгоритмов, которые в результате проведения оптимизации кода могут существенно отличаться от исходных. Как правило, достаточно эксплуатировать базу в таком режиме 3-5 дней, после чего можно включить режим оптимизации для всех.
Включение и выключение режима оптимизации производится с помощью предопределенного элемента «ВключениеОптимизации» справочника «ДопКонстанты».
Включение и выключение режима для всех пользователей производится установкой поля «Значение» элемента «ВключениеОптимизации» в «Истина» или «Ложь» соответственно. Для этого можно использовать флаг «Оптимизация включена для всех пользователей» в обработке ТестПроведения.
Для включения оптимизированных обработчиков только для конкретного пользователя необходимо добавить в табличную часть «Значения» элемента «ВключениеОптимизации» строку, поместив в поле «Ключ» код пользователя, а в поле «Значение» — значение «Истина».
Для включения/выключения использования определенной оптимизированной процедуры(функции), необходимо добавить в табличную часть «Значения» элемента «ВключениеОптимизации» строку, поместив в поле «Ключ» имя этой процедуры, а в поле «Значение» — значение «Истина» или «Ложь» соответственно.

Все эти настройки реализованы в тестовой демонстрационной базе.

Заключение

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

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

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

● Файлы для скачивания:

для получения доступа требуется авторизация размер: 107.8 кб, скачиваний: 17. cодержимое архива: ТестОптимизацииУправляемыеФормы.dt — 110,4 кб.

для получения доступа требуется авторизация размер: 108.3 кб, скачиваний: 15. cодержимое архива: ТестОптимизацииОбычныеФормы.dt — 110,9 кб.

Нет комментариев

Источник: itdemka.ru