Лучшим инструментом для анализа производительности отдельного отчета является ST12, поэтому, если у вас есть возможность, отследите его.
Мы должны догадаться, что без трассировки самая большая проблема заключается либо в SELECT с подвыбором, либо в MODIFY.

1) SELECT в LOOP всегда медленные

Здесь вы фактически делаете два для каждой строки в it_collectoraction.

Попробуйте уменьшить количество SELECT

В зависимости от количества строк с одним и тем же dat может быть намного быстрее заменить SELECT в LOOP на SELECT с FOR ALL ENTRIES из zcollectoraction вне LOOP и найти MAX (время) на стороне ABAP.

Покрытие индекса

Кажется, все в порядке.

2) MODIFY работает медленно на СТАНДАРТНЫХ таблицах.

Вы должны просеять всю таблицу, чтобы найти соответствующую строку. Если вы определите it_collectoraction как SORTED, это будет намного быстрее. Если вы используете символ поля в LOOP, его можно вообще избежать.

Кодирование

Замените свой LOOP на это:

TYPES: BEGIN OF tty_coll_act,
        bukrs TYPE burks,
        kunnr TYPE kunnr,
        dat   TYPE dat,
        time  TYPE time,
      END OF tty_coll_act.

DATA: lt_coll_act TYPE TABLE OF tty_coll_act,
      ls_coll_act LIKE LINE OF lt_coll_act.

FIELD-SYMBOLS: <fs_collectoraction> LIKE LINE OF it_collectoraction.

SELECT bukrs kunnr dat time
    INTO TABLE lt_coll_act
    FROM zcollectoraction
    FOR ALL ENTRIES IN it_collectoraction
    WHERE bukrs = wa_collectoraction-bukrs AND
          kunnr = wa_collectoraction-kunnr AND
          dat   = wa_collectoraction-dat.

SORT lt_coll_act BY bukrs kunnr dat time DESCENDING.

LOOP AT it_collectoraction ASSIGNING <fs_collectoraction>.
" the READ TABLE finds the first matching row,
" it will be MAX(TIME) as TIME is sorted descending       
  READ TABLE lt_coll_act INTO ls_coll_act
      WITH KEY  bukrs = <fs_collectoraction>-bukrs
                kunnr = <fs_collectoraction>-kunnr
                dat   = <fs_collectoraction>-dat BINARY SEARCH.
  <fs_collectoraction> = ls_coll_act.
ENDLOOP.

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

Добавление запросов выбора внутри цикла всегда замедляет выполнение приложения, поскольку приложение должно выполнять запросы к базе данных для каждого цикла. Загрузка всей необходимой информации во внутреннюю таблицу и последующая обработка данных в приложении выполняются намного быстрее.

Дайте мне знать, если вам потребуется дополнительная информация по этому вопросу.

Прежде всего, я хочу поблагодарить всех вас за вашу помощь. Я изменяю логику выбора, используя внутреннюю таблицу со всеми записями из dbtab в соответствии с данными выбора пользователя. Итак, код стал следующим:

DATA: wa_collectoraction TYPE zcollectoraction,
  it_collectoraction TYPE TABLE OF zcollectoraction,
  itsort_collectoraction TYPE HASHED TABLE OF zcollectoraction
      WITH UNIQUE KEY mandt bukrs kunnr yearmonth dat time.

FIELD-SYMBOLS: <fs_collectoraction> LIKE LINE OF it_collectoraction.

SELECT bukrs kunnr yearmonth MAX( dat ) AS dat
  FROM zcollectoraction
    INTO CORRESPONDING FIELDS OF TABLE it_collectoraction
  WHERE bukrs IN so_bukrs AND
        kunnr IN so_kunnr AND
        dat   IN so_date
  GROUP BY bukrs kunnr yearmonth.

" Keep the total records which will be inserted.
i_tab_lines = sy-dbcnt.

SELECT * INTO TABLE itsort_collectoraction
  FROM zcollectoraction
  WHERE bukrs IN so_bukrs AND
      kunnr IN so_kunnr AND
      dat   IN so_date.

SORT itsort_collectoraction
            BY mandt bukrs kunnr yearmonth dat time DESCENDING.

LOOP AT it_collectoraction ASSIGNING <fs_collectoraction>.
  PERFORM progress_bar USING 'Retrieving data...'(035)
                             sy-tabix
                             i_tab_lines.

  READ TABLE itsort_collectoraction INTO wa_collectoraction
      WITH KEY bukrs = <fs_collectoraction>-bukrs
                kunnr = <fs_collectoraction>-kunnr
                yearmonth = <fs_collectoraction>-yearmonth
                dat   = <fs_collectoraction>-dat.
  <fs_collectoraction> = wa_collectoraction.
ENDLOOP.

Этот код запускает 43000 записей за 1 минуту. Единственная проблема в том, что после первых 10000-15000 записей процесс замедляется. Я не знаю, есть ли какая-либо команда для очистки чего-либо. Я не знаю, что очистить.

Еще раз большое спасибо всем вам. С уважением Элиас

PS. В первые 10 секунд он обрабатывает 14 000 записей. За 1 минуту обработано 38 500, а за 1 минуту и ​​50 секунд завершено 54 500 записей. У меня создается впечатление, что он выполняет что-то, что замедляет процесс. ЕСТЬ ИДЕИ?

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

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

SELECT bukrs kunnr yearmonth dat time
FROM zcollectoraction
  INTO CORRESPONDING FIELDS OF TABLE it_collectoraction
WHERE bukrs IN so_bukrs AND
      kunnr IN so_kunnr 
.

Удалить неключевые поля из itab:

DELETE it_collectoraction WHERE dat NOT IN so_date.

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

SORT it_collectoraction BY bukrs kunnr date DESCENDING time DESCENDING.

Удалить все соседние (= все с одинаковым ключом сравнения после первого) записи для bukrs и kunnr

DELETE ADJACENT DUPLICATES FROM it_collectoraction COMPARING bukrs kunnr.