Оптимизация 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) индекс, индекс, индекс!


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

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

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

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

  3. выберите из БД по всем ключевым полям. Если это невозможно, подумайте о создании индексов. Для небольших и простых выборок используйте joins. Для больших выборов с использованием соединений все равно будет работать быстрее, но будет трудно следить.

  4. незначительная вещь - используйте символы поля для чтения строки таблицы, это делает его много быстрее.


Это в основном для целей согласованности, поэтому ваш код приятно смотреть на


1) Вы должны быть осторожны при использовании оператора SELECT на языке ABAP. Ненужные подключения к базе данных значительно уменьшается производительность программы ABAP.

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

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

3) Не следует использовать внутренние таблицы с workarea.

4)при использовании вложенные циклы, использовать алгоритмы сортировки.


они такие же, как ADD ключевого слова + оператора.

если вы хотите оптимизировать свой ABAP, я нашел самых больших преступников:

  • Не использовать двоичные запросы и/или (внутренние) ключи таблицы должным образом. Синтаксис ABAP является мертвым мозгом, когда дело доходит до использования таблицы. Ноу-хау эффективно работать со столами. В основном пишите лучший / оптимальный / элегантный код высокого уровня. Это всегда победитель!

  • меньше инструкции == меньше времени. Чем меньше инструкций вы нажмете быстрее программа будет работать. Это важно в узких петлях... Я знаю, это звучит очевидно, но ABAP настолько медленный, что если вы действительно пытаясь оптимизировать критические программы, это будет иметь значение. (У нас есть процессы, которые работают дни... и сбриваю час или около того. имеет значение!)

  • Не смешивайте типы. Есть немного накладных расходов для некоторых неявное преобразование... например, если вы инициализация string тип данных, затем используйте правильную литеральную строку с (Апостроф) цитаты: "литерал". Это также считается для поиска в таблицы с использованием клавиш... используйте точные типы данных соответствия.

  • функции звонки... Я не могу подчеркнуть накладные расходы на вызовы функций достаточно... чем меньше у тебя денег, тем лучше. Идет против всего реального программист верит, но тут уж ничего не поделаешь... Авар является особый случай.

  • цикл с помощью ASSIGNING (или REF TO - немного медленнее, на некоторых типы), избегайте как чумы.

PS: также имейте в виду, что SWITCH заявления просто прославляются IF условные... таким образом, переместите наиболее распространенные условия на вершину!


вы можете создавать компакт-диски с помощью ADT Eclipse. Или представления (se11) имеют хорошую производительность для выбора.