"
Supported by

With many fields avoid INTO CORRESPONDING FIELDS

I have already advised here that, in tables with many fields, it’s always recommended to avoid using SELECT *, you must always select, explicitly, only the necessary fields.

But I didn’t warn you that there’s yet another optimisation worth making: avoid INTO CORRESPONDING FIELDS OF TABLE.

I have made the following experiments with the BSAD table:

  1. Select the whole table to an internal table with the same structure;
  2. Select only 4 fields to an internal table with the BSAD’s structure using INTO CORRESPONDING FIELDS;
  3. Select only 4 fields of the BSAD table to an internal table containing only those 4 fields and still using INTO CORRESPONDING FIELDS;
  4. Select only 4 fields of the BSAD table.

These are the results:

 Duration%x
154.12s100% 
23.40s6.3%16x
30.74s1.4%71x
40.70s1.3%77x

Which translates into:

  1. Tragedy. Avoid at all cost. But we already knew this;
  2. It takes only 6.3% to select the fields, that is to say, almost 16x faster than the lazy and dirty approach;
  3. Sending the fields to a small structure instead of sending them to a big one takes only 1.4%. That’s 71x faster than the tragic approach and 4.5x faster than the previously recommended approach;
  4. Avoiding the use of INTO CORRESPONDING when the structure is already small, you still profit slightly, but it’s not all that relevant.

You’ve been warned.

Note that the advantage in using INTO CORRESPONDING FIELDS is to add some measure of safety since it maps the fields automatically. In case this command isn’t used, you must ensure the destination structure’s fields are all there, and in the same order by which they are shown in SELECT.

Here’s the program used to obtain the results:


REPORT zzt_into_corresponding.

TYPES: BEGIN OF ty_campos,
         bukrs TYPE bukrs,
         belnr TYPE belnr_d,
         gjahr TYPE gjahr,
         buzei TYPE buzei,
       END OF ty_campos.

DATA: t_bsad_todos  TYPE STANDARD TABLE OF bsad,
      t_bsad_poucos type STANDARD TABLE OF bsad,
      t_campos      TYPE STANDARD TABLE OF ty_campos,
      rtime0        TYPE i,
      rtime1        TYPE i,
      rtime2        TYPE i,
      rtime3        type i,
      rtime4        type i.

GET RUN TIME FIELD rtime0.

SELECT * FROM bsad 
  INTO CORRESPONDING FIELDS OF TABLE t_bsad_todos.
GET RUN TIME FIELD rtime1.

SELECT bukrs belnr gjahr buzei FROM bsad 
  INTO CORRESPONDING FIELDS OF TABLE t_bsad_poucos.
GET RUN TIME FIELD rtime2.

SELECT bukrs belnr gjahr buzei FROM bsad 
  INTO CORRESPONDING FIELDS OF TABLE t_campos.
GET RUN TIME FIELD rtime3.

SELECT bukrs belnr gjahr buzei FROM bsad 
  INTO TABLE t_campos.
GET RUN TIME FIELD rtime4.

rtime0 = rtime1 - rtime0.
rtime1 = rtime2 - rtime1.
rtime2 = rtime3 - rtime2.
rtime3 = rtime4 - rtime3.

WRITE: / 'SELECT *', 50 rtime0,
       / 'SELECT campos INTO CORRESPONDING', 50 rtime1,
       / 'SELECT campos INTO CORRESPONDING estrutura', 50 rtime2,
       / 'SELECT campos INTO estrutura', 50 rtime3.

For the petty ones, it’s true that to obtain more precise values you would have to run this several times and change the order to obtain averages and to go around caches. But the differences are so blunt, there’s not much doubt left. Besides, I’ve tried to reverse the SELECTs order and the proportions remained unchanged.

Thank you Sérgio Fraga for the tip.

Thank you metalkpirate1day for the photo.

Greetings from Abapinho

4 comentários a “With many fields avoid INTO CORRESPONDING FIELDS”

  1. Custodio Diz:

    Ola Nuno,

    Ando meio sumido do seu blog, e quando apareco para discordar de ti. Veja esse blog post na SCN, feito pelo Thomas Zloch: http://scn.sap.com/docs/DOC-33976

    Abraco
    Custodio

  2. Nuno Godinho Diz:

    Olá Custodio, realmente é intringante. Obrigado por me mostrares isto. Vou ter de comparar os meus exemplos com os exemplos por ele apresentados. Porque os meus exemplos realmente mostram que o MOVE-CORRESPONDING é mais lento. Deve depender das situações.

  3. Giancarlo Fernandes Diz:

    Ola,

    Na minha humilde opinião, esse código não é válido para comparação de tempos de execução, da forma como foi proposto.

    Sempre que fazemos o PRIMEIRO acesso a uma informação qualquer no banco de dados, esta SEMPRE levará mais tempo do que os demais acessos à mesma informação, isto se deve pelo fato de no primeiro acesso não existir dados em cache no servidor de banco de dados.

    Se voce repetir 2 vezes o mesmo “SELECT *” nesse seu exemplo, vai notar que na segunda vez ele irá rodar extremamente mais rápido que na primeira vez, pois nesta segunda vez, como o servidor de banco de dados já fez cache em memória RAM, ele não irá ler dados fisicamente no disco rígido (que é lento), ao invés disso, ele vai ler diretamente do cache em memória RAM (que é muito mais rápido).

    Faça o teste no seu código, adicione uma variável “rtime5” e repita o “SELECT *” logo após o primeiro “SELECT *” e veja os tempos de execução.

    Abraço,
    Gian

  4. Nuno Godinho Diz:

    Olá Giancarlo,

    De facto, tens toda a razão. O teste é muito pouco científico :) Ainda assim, experimentei inverter a ordem dos SELECTs (sabendo que uns continuam a afectar os outros) e os resultados foram consistentes:

    SELECT campos INTO estrutura 24.955
    SELECT campos INTO CORRESPONDING estrutura 24.512
    SELECT campos INTO CORRESPONDING 144.042
    SELECT * 956.909

    Mas o mais cómico é que por engano corri o programa no mandante de desenvolvimentos, que não tem dados (a BSAD tem 0 registos) e o mais rápido foi de longe o SELECT * eh eh

Deixe um comentário


About Abapinho
Abapinho runs on WordPress
Articles (RSS) e Comments (RSS).