Оптимизация ABAP
есть ли какой-либо прирост производительности между "перейти к" vs x = y? У меня есть очень старая программа, которую я оптимизирую, и хотел бы знать, стоит ли вытаскивать весь ход. Любые другие общие советы по оптимизации ABAP также были бы отличными.
8 ответов
нет, это просто та же операция выраженная двумя разными способами. Там ничего не выиграешь. Если вы за общие подсказки,есть хорошая книга доступна Это я бы рекомендовал изучить подробно. Если вам нужно оптимизировать конкретную программу, используйте инструменты трассировки (transaction SAT
в достаточно текущих выпусках).
эти два утверждения эквивалентно:
" Чтобы присвоить значение источника объекта данных назначению переменной, используйте следующую инструкцию:
MOVE source TO destination.
или эквивалент заявлением
destination = source.
"
нет, они одинаковые.
вот несколько быстрых советов из моих лет повышения производительности:
1) Если вы используете move-соответствие, где это возможно, ваш код может быть намного более кратким, модульным и расширяемым (в далеком прошлом это было неодобрительно, но технические причины этого, как правило, больше не применимы).
2) Используйте SAT при каждой возможности и обязательно включите внутреннее отслеживание таблицы. Это как включить свет. против того, чтобы спотыкаться о мебель в темноте.
3) сделайте слой базы данных как можно больше работы для вас. Старайтесь по возможности комбинировать запросы, особенно при комбинировании результирующих наборов. Два запроса, связанные соединением, обычно намного лучше, чем select > itab > select для всех записей.
4) это немного продвинутый, но для всех записей часто имеет гораздо более низкую производительность, чем эквивалентные select-options во фразе. Это, по-видимому, потому, что последний построен как один большой запрос к слою базы данных, в то время как первый требует нескольких поездок к слою базы данных. Оговорка, конечно, заключается в том, что если у вас слишком много записей в ваших параметрах выбора, сгенерированный запрос на уровне базы данных превысит допустимый размер в вашей системе, но в пределах этого ограничения возможны большие повышения производительности. В общем, SAP просто обожает select-options.
5) индекс, индекс, индекс!
прежде всего, перемещение не влияет на большую производительность.
Что влияет довольно много в проектах, над которыми я работал, это следующее:
вложенные петли (очень злые). Например, цикл через все документы, и для каждого документа выберите один, чтобы проверить его код компании разрешено отображать. Вместо этого составьте список кодов компаний, проконсультируйтесь с ними один раз из БД и обратитесь к этой таблице результатов.
использовать хэш или сортированные таблицы, где это возможно. Где это невозможно, используйте стандартную таблицу, но отсортируйте ее по ключам и используйте "двоичный поиск".
выберите из БД по всем ключевым полям. Если это невозможно, подумайте о создании индексов. Для небольших и простых выборок используйте joins. Для больших выборов с использованием соединений все равно будет работать быстрее, но будет трудно следить.
незначительная вещь - используйте символы поля для чтения строки таблицы, это делает его много быстрее.
1) Вы должны быть осторожны при использовании оператора SELECT на языке ABAP. Ненужные подключения к базе данных значительно уменьшается производительность программы ABAP.
2) при использовании внутренней таблицы с функциями, вы должны назвать его по ссылке, чтобы уменьшить использование памяти.
Вызов По Ссылке: Передает указатель на ячейку памяти.Изменения, внесенные в переменная внутри подпрограммы влияет на переменную снаружи этот подпрограмма.
3) Не следует использовать внутренние таблицы с workarea.
4)при использовании вложенные циклы, использовать алгоритмы сортировки.
они такие же, как ADD
ключевого слова +
оператора.
если вы хотите оптимизировать свой ABAP, я нашел самых больших преступников:
Не использовать двоичные запросы и/или (внутренние) ключи таблицы должным образом. Синтаксис ABAP является мертвым мозгом, когда дело доходит до использования таблицы. Ноу-хау эффективно работать со столами. В основном пишите лучший / оптимальный / элегантный код высокого уровня. Это всегда победитель!
меньше инструкции == меньше времени. Чем меньше инструкций вы нажмете быстрее программа будет работать. Это важно в узких петлях... Я знаю, это звучит очевидно, но ABAP настолько медленный, что если вы действительно пытаясь оптимизировать критические программы, это будет иметь значение. (У нас есть процессы, которые работают дни... и сбриваю час или около того. имеет значение!)
Не смешивайте типы. Есть немного накладных расходов для некоторых неявное преобразование... например, если вы инициализация
string
тип данных, затем используйте правильную литеральную строку с (Апостроф) цитаты: "литерал". Это также считается для поиска в таблицы с использованием клавиш... используйте точные типы данных соответствия.функции звонки... Я не могу подчеркнуть накладные расходы на вызовы функций достаточно... чем меньше у тебя денег, тем лучше. Идет против всего реального программист верит, но тут уж ничего не поделаешь... Авар является особый случай.
цикл с помощью
ASSIGNING
(илиREF TO
- немного медленнее, на некоторых типы), избегайте как чумы.
PS: также имейте в виду, что SWITCH
заявления просто прославляются IF
условные... таким образом, переместите наиболее распространенные условия на вершину!
вы можете создавать компакт-диски с помощью ADT Eclipse. Или представления (se11) имеют хорошую производительность для выбора.