Господа!
Чисто для проверки сделал две программы
первая:
data: tab_1 like ... occurs ... with header line.
data: tab_2 like ... occurs ... with header line.

select * from ... into table tab_1.
select * from ... into table tab_2.

loop at tab_1.
loop at tab_2 where field1 = tab_1-field_1 and
field2 = tab_1-field_2.
endloop.
endloop.

и вторая:
data: tab_1 like ... occurs ... with header line.
DATA: tab_2 LIKE SORTED TABLE OF ...
WITH NON-UNIQUE KEY field_1 field_2
WITH HEADER LINE.

select * from ... into table tab_1.
select * from ... into table tab_2.

loop at tab_1.
loop at tab_2 where field1 = tab_1-field_1 and
field2 = tab_1-field_2.
endloop.
endloop.

В итоге получилось что второй вариант работает медленне чем первый. почему так?

Не понял. А какой смысл этого ответа?

Сколько это в граммах\секундх и какой объём данных - потеря произвотительности может быть, например, на построении индекса.

И я сейчас не помню - использует-ли LOOP индекс для доступа - посмотрите в расширенной проверке - нет ли ругани на данный LOOP/

Расширеная проверка програмы все выдала по нулям.
В tab_1 около 53121 записей.
В tab_2 около 10189 записей.
первый вариант выполняется примерно за 134 секунды
второй переваливает за 230.

Да и вообще как-то немного даже нелогично чтобы LOOP не смотрел ключевые поля.

неужто везде придется править на read и потом while?

Быть может, тратится время, чтобы сделать таблицу tab_2 во второй программе сортированной. Посмотрите на время выполнения программ, убрав из них loop

насколько помню loop where всегда дает полный обход внутренней таблицы. Лучше внутри внешнего цикла использовать read table.

F1 (на LOOP) напоминает:
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 the WHERE condition be specified in the form

WHERE k1 = v1 AND k2 = v2 AND ... AND kn = vn

where the components k1, ..., kn are in the same sequence as the beginning of the table key.

_gary_, или, лучше, оформите выборку и циклы через perform, а потом сообщите время, полученное на них в динамическом анализе.

Ну в принципе вот что получилось
время по первому циклу занимает 208 001 531 мкс
второй цикл вызывается 53 121 раза и занимает в сумме
207 868 879 мкс

Что и требовалось доказать

Смысл этого ответа в том, что второй вариант у тебя, теоритически, откушивает время на сортировку таблицы tab_2. Замерь времена селектов. Я не знаю на сколько у тебя индекс таблицы репозитария из которой делается селект соотноится с индексом внутренней таблицы. Но после того как данные переданы от сервера БД к аппликейшену - происходит еще упорядочивание записей во внутренней таблице, раз уж она у тебя индексированная.....

Еще неплохо посмотреть реальные значения field1 и field2 во второй таблице. Например, если большинство значений стремится к field1 = '00000002' и field2 = '0001', то и выигрыша в производительности не будет.

Всегда делаю так и не трачю время на эксперименты:

По производительности можно сравнить со следующей конструкцией:

-------------------------------------------------
У ABAPERA всегда есть время на подвиг

Неужели постоянно возникают задачи, в которых эта экономия настолько существенна??

Может вообще стоит подобные циклы в виде внешних call`ов на сервере приложений реализовывать?

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



P.S. А ещё можно динамически генерировать код для обработки определённых таблиц в зависимости от математической модели распределения ключей в таблице.