Пока одним обходимся. А вот describe table lines работает медленней чем lines( ).

Особенно когда речь идет об оперативных отчетах

Эт вопрос спорный У нас система не спит.... Круглые сутки идет пакетная загрузка производственных заказов

Для начала хотелось бы увидеть структуру tab_2 и tab_1!

сделал в виде:
loop at tab_1.
read table tab_2 with key field_1 = tab_1-field_1
field_2 = tab_1-field_2.
if sy-subrc = 0.
sidx = sy-tabix.
while tab_2-field_1 = tab_1-field_1 and tab_2-field_2 = tab_1-field_2.

...чето делаем

sidx = sidx + 1.
read table tab_2 index sidx.
if sy-subrc <> 0.
exit.
endif.
endwhile.
endif.
endloop.

Отработало за 20сек.

2 all
код _gary_ может работать с ошибками на системах 4.0 и 4.6С
2 _gary_
1 огласите pls версию системы на которой работаете
2 select * всегда работает медленней чем select[необходимый список полей]
3 В конструкцию read table tab_2 with key field_1 = tab_1-field_1 field_2 = tab_1-field_2 не повредит добавить transporting no fields

у нас система 4.6.

про select с необходимыми полями и no-transporting - это все понятно, но это уже от задачи зависит. Я же просто проверял.
Меня интересовал просто сам факт: почему с отсортированой таблицей код работает намного медленнее, чем с неотсортированой.

не надо обобщать частный случай до тендеции,
1 Видимо в tab_2 field_1 field_2 в каждой итерации составляют малый процент данных.
2 loop .... assigning на любой версии приносят повышение производительности это тоже резерв по скорости.
3 после многократного повтора выборки по одним и тем же данным
данные лежат в кеше базы данных - оттуда и такое радикальное повышение производительности.

Эти результаты касаются какого кода, первого со вложенными loop или второго с read?
Read без бинарного поиска ишет последовательно до первого нахождения по ключу. В неотсортированной таблице запись с совпадающим ключем может быть ближе к началу. Случайное совпадение, но результат неожиданный. Надо данные Ваши смотреть, без них конкретные показатели обсуждать бесполезно.

может время тратится на сортировку в бд?
если попробовать так
data tab_dummy like standard table of tab2. "header line от tab2
select ... into table tab_dummy.
tab2[] = tab_dummy.
и дальше как было

Если все еще интересует, ответь на мой предыдущий пост.

ИМХО: максимальная производительность будет если сделать так:
data: tab1 type table of typ1,
tab2 type sorted table of typ2 with non-unique key f1 f2,
dummy type table of typ2,
tabix type sy-tabix.
field-symbols: <wa1> type typ1,
<wa2> type typ2.

select .... into table tab1 where ...
select .... into table dummy where ....

* сортировка на appl серваке, а не на бд
sort tab1 by f1 f2.
tab2[] = dummy[].

tabix = 1.
loop at tab1 assigning <wa1>.
"assigning для большой строки (много полей, структ,
"влож. таблицы) лучше чем into

loop at tab2 assigning <wa2>
from tabix "чтоб оптимизировать начало
where f1 = <wa1>-f1
and f2 = <wa1>-f2. " имеено в том порядке как при опред. ключа
tabix = sy-tabix + 1."для старат след итерации в tab1

"do smth...

endloop.

endloop.

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

по крайней мере я стараюсь делать примерно так в своих прогах

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