Оптимизация loop where

Морской

Каким образом можно оптимизировать конструкцию:
loop at itab where n1 = val1 and
......
nN = valN.
endloop.

T

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

sibrin

T написал:

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

Если loop...endloop выполняется немного раз, то сортировка займёт больше времени.

T

Да, сортировка может здорово отнять время. Но суть в том, что loop по упорядоченым ключам пройдёт быстрее.

PS. Не, не прав. На самом деле скорость увеличится лишь для SORTED TABLE. Для STANDARD и HASHED всегда бежим по всем..

PS2 И ещё

Цитата:

Performance when processing a LOOP AT ... WHERE statement improves considerably if the fields compared are of the same type. For best results, define your comparison fields as follows:

DATA comparison field LIKE table field.

Example:

DATA: CMP_NAME LIKE STRUC-NAME.

CMP_NAME = 'Harold'.
LOOP AT ITAB INTO STRUC WHERE NAME = CMP_NAME.
WRITE: / STRUC-NAME, STRUC-SALDO.
ENDLOOP.

Lars

assigning тоже неплохо использовать.

T

Да, точно. Причём использовать типизированный field-symbol.

sibrin

Уйду в оппозицию: "same type" и assigning помогут, если мало where и много отобранных записей.

Я так понял вопрос, что много where и мало отобранных записей.

Если не все where равнозначны, то в sorted table можно первыми расположить столбцы с наиболее жёсткими ограничениями. Таким образом как правило будет использоваться только часть ключа.

T

Да ладно, причём тут оппозиция.Есть вещи, которые стоит иметь ввиду. Вот и всё.

Same type - это то, что никогда не помешает.
Assigning - выигрыш примерно после 5-ти строк. А если придётся менять найденные данные - то выигрыш сразу.
Sorted - по любому поможет если отбор по ключевым полям начиная слева. Вес ключевых полей тоже стоит учесть при их расположении.

ЗЫ

Цитата:

When you use the WHERE condition with a STANDARD or HASHED table, a full table scan is always required.

If you are working with a SORTED TABLE, the partial sequential processing can be optimized so that only the entries that actually satisfy the WHERE condition are processed. This optimization requires that each sub-condition is linked with AND; that no parentheses are used; that at least one sub-condition is in the form k = v; and that the conditions in the form k1 = v1 ... kn = vn cover at least the first part of the table key.

The starting point for the loop is specified using a binary search with the sub-conditions that cover the table key (partially or completely). This optimization is similar to the optimization in the READ statement. The loop is only processed from the starting point to the point where these sub-conditions are still met.

Mike1

еще один вариант без сортированной таблицы,
таблица сортируется по полям n1 nN
идет read table with key n1 = ... nN =
binary search
если оно успешно запоминается sy-tabix
читаются "окружаюшие" записи
read table index " sy-tabix - 1 "
read table index "sy-tabix + 1"
и проверятся их ключи n1 = ... nN =

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

Jelena

Морской написал(а):

Каким образом можно оптимизировать конструкцию:
loop at itab where n1 = val1 and
......
nN = valN.
endloop.

Еще такое свежее решение: а почему бы не перенести WHERE в SELECT, который заполняет таблицу itab? В чем вообще сакральный смысл такого построения LOOP в вашем случае?

Monarch

Jelena написала:

Морской написал(а):

Каким образом можно оптимизировать конструкцию:
loop at itab where n1 = val1 and
......
nN = valN.
endloop.

Еще такое свежее решение: а почему бы не перенести WHERE в SELECT, который заполняет таблицу itab? В чем вообще сакральный смысл такого построения LOOP в вашем случае?

Точно, Морской, код в студию! :lol:

Морской

Есть одна лохматая прога - работает правильно,но очень долго.
select подправил - убрал все endselect. Остались внутр таблицы.
Надо оптимизировать

Monarch

Морской написал(а):

Есть одна лохматая прога - работает правильно,но очень долго.
select подправил - убрал все endselect. Остались внутр таблицы.
Надо оптимизировать

И все-таки хочется посмотреть на конкретную реализацию, а не общие условия :shock:

Хотя бы покажи объявления 2-х внутренних таблиц и конкретные условия твоего LOOP ... ENDLOOP.

Monarch

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

1. Возможно, некоторые записи этих таблиц заведомо не будут обрабатываться - удалить их предварительно
2. Еслии обработка идет 1 к N, то удалять записи 2-й таб. сразу после обработки
3. Использовать LOOP с addition FROM ...
4. Если сравнение по полям K1 ... KN идет четко на '=' и их типы совпадают, то разместить их вначале внутренних таблиц
в одинаковом порядке и делать CHECK itab1(XXX) = itab2(XXX) внутри LOOP.

Удав

Если таблица itab большая, то имеет смысл сделать таблицу сортированной по полям, на которые объявлено равенство, или выбирать данные непосредствнно из БД в цикле по itab2 вместо одной выборки в itab2.
По поводу сортировки:
-Для стандартных таблиц, сортированных по ключу, Поиск первой записи по условиям ведется с помощью двоичного поиска, вся остальная обработка ведется перебором.
-Для сортированных таблиц поиск всех записей ведется всегда с помощью двоичного поиска.
Поэтому в itab2 в любом случае необходимо правильно расположить в начале таблицы поля, по которым осуществляется поиск.
И вообще, в примерах производительности в SE38 очень хорошо рассказано про внутренние таблицы и работу с ними.

Правила форума

Оптимизация loop where

Кто сейчас на конференции