SORT and GROUP BY

[sap_rocks]

Imagine a source code like this where we first sort an internal table and directly after that group by:

SORT lt_data_aqua BY lgtyp lgber.
LOOP AT lt_data_aqua ASSIGNING FIELD-SYMBOL(<ls_data_aqua>)
  GROUP BY <ls_data_aqua>-lgber ASSIGNING FIELD-SYMBOL(<lg_aqua_lgber>).
  [...]
ENDLOOP.

In this case we sort by storage type and storage section and then group by storage section. The sorting algorithm of GROUP BY wouldn't have to sort the internal table by storage type and section as we already did this by SORT previously.

Does the SORT have a positive impact on performance on the following GROUP BY statement by presorting the related internal table?

Many thanks in advance for your help!

[DominikTylczyn]

Hello mraht

That is a very good question. I think it is explained in the SAP Help on LOOP AT itab GROUP BY:

Grouping

In the first phase, all rows specified by the conditions cond are read in the processing order specified in a loop across rows. The statements in the statement block between LOOP and ENDLOOP are not executed during this operation. For each row read, a group key is constructed in the group key expression group_key instead. Each group key represents a group. Each row is assigned to precisely one group (as a member). This is the group of all rows with the same group key. If the addition WITHOUT MEMBERS is not used, this assignment is internal and can be used for access to the members of a group in the second phase.

So it looks like LOOP AT ... GROUP BY doesn't use any sorting. First it reads the entire table to build groups.

Best regards

Dominik Tylczynski

[sap_rocks]

That means that the presorting doesn't have any effect on the performance at all and would only be useful if the following process would depend on the sorting. Thanks for the clarification!

[Sandra_Rossi]

mraht No, it explains a few things not related to the performance, so you can't conclude that it has an effect or not on the performance, and even if after lots of tests you could conclude anything, maybe it could change in the future without warning. But consider that SAP takes that in charge internally and probably they do the "best" they can, as for anything else (like hopefully sorting is probably done the "best" way possible, considering the algorithm, memory available, and so on).

[sap_rocks]

Hi sandra.rossi, ok, from the description I assumed that GROUP BY reads all entries regardless of the presorted table entries, determines groups during this process and appends the current row/entry of the itab to a suitable group (e.g.: read row N, suitable group available? y: assign entry to it, n: create new group and assign entry to it). But you're right: as we don't know the actual or future algorithm of GROUP BY we don't know whether a presorting has/could have some positive effect on the performance. I just try to figure out if it currently has a positive effect:).