✒️ABAP / La performance en ABAP Por Candela Calzada

Unidad n°7: Los Batch Inputs vs las BAPIS y temas avanzados
Lección n°7: La performance en ABAP

En ABAP existen buenas y malas practicas, ya sea porque afectan al rendimiento o la performance de los programas o porque afectan a otros factores que son determinantes como ser la reutilización y el mantenimiento del cód. Entonces, cuando hablamos de performance, nos referimos al análisis del desempeño y rendimiento del programa.

La performance de un programa tiene que ver con tres aspectos fundamentales:

1. El tiempo de procesamiento de la lógica ABAP existente en el programa.
2. El tiempo de procesamiento de los accesos a las TBD.
3. El tiempo de procesamiento del sist. SAP.

De estos tres aspectos, debemos hace incapie es en el tiempo de procesamiento de los accesos a las TBD, ya que es el que más recursos y tiempo consume.

En segundo lugar, está el tiempo de procesamiento de la lógica ABAP existente en el programa, es decir, una vez que recuperamos los datos de las TBD, debemos procesarlos mediante una lógica determinada y producir una acción en el sist. o una salida por pantalla.
Y, en tercer lugar está el tiempo de procesamiento del sist. SAP.

ABAP brinda una herramienta para evaluar como se distribuye el tiempo de procesamiento de un programa, el "Análisis de tiempo de ejecución" de la trans SE30.

Dentro de la trans, veremos una pantalla inicial donde seleccionamos la opción Programa, completamos el nombre del programa que deseamos evaluar, en este caso ZTEST_SELECT_USUARIOS (que es un reporte que hace un SELEC a la TBD de usuarios ZTABLA_USUARIOS y luego muestra los registros por pantalla mediante un reporte ALV).
Y por último hacemos clic en el botón Evaluar.

Como resultado de la ejecución de la trans. veremos una gráf. donde podemos ver cual es la distribución del porcentaje de los tipos de procesamiento entre la lógica ABAP, la base de datos y el sist:

Entonces podemos decir que:

• Cuanto más alto es el porcentaje de procesamiento de la base de datos en comparación a los otros porcentajes, entonces los tiempos del programa se irán a las nubes.
• La situación ideal es que el porcentaje de procesamiento de la lógica ABAP sea lo más alto posible y el del procesamiento de la base de datos sea lo más bajo posible.
• Para lograr este objetivo es importante tener en claro que prácticas son desaconsejadas y cuales son recomendadas, de modo de poder apuntar a realizar programas de alta calidad, que funcionen bien en el ambiente productivo, donde las TBD contienen millones de registros y cada micro seg. cuenta.

Las buenas y malas practicas en el acceso a la base de datos:

Evitar el SELECT*:

• Cuando hacemos un SELECT a una TBD tenemos que evitar usar el asterisco, si es que no necesitaremos recuperar todos los campos de la tabla, ya que si lo hacemos estaremos recuperando campos de las TBD que no usaremos.
  EJ:
  
• En lugar de usar el asterisco en el SELECT, deberíamos especificar cada uno de los campos de la TBD que queremos recuperar.
  EJ:
  

Evitar el SELECT ENDSELECT:

• Cuando seleccionamos los registros de una TBD, podemos ejecutar la sentencia SELECT ENDSLECT, que a diferencia de SELECT, hace un bucle que inicia con SELECT y finaliza con ENDSELECT y dentro del bucle se puede hacer el procesamiento del registro recuperado de la TBD:
  
• No es aconsejable usar el SELECT ENDSELECT debido a que la performance de la sentencia SELECT INTO TABLE es muy superior:
  
• La 2da opción es ocho veces más performante.

Evitar el SELECT sin WHERE:

• Un SELECT sin condiciones, es decir, sin la cláusula WHERE, devuelve todos los registros de la TBD. En general esto indica que se ha producido un error de programación. Pero en casos específicos podremos usarlo sin WHERE.
  EJ:
  
• También, cuando ejecutamos un SELECT es recomendable que las condiciones sean lo más específicas posibles, ya que de esta forma el acceso a los registros resultantes sería más rápido que si no se especificaran.
  EJ:
  
• Además debemos evitar incluir condiciones por el negativo (NE), ya que desde el pto de vista del rendimiento son mucho más costosas a nivel base de datos.

Evitar el SELECT dentro de un LOOP:

• Muchas veces veremos uno o varios SELEC dentro de un LOOP-ENDLOOP, es decir, mientras recorremos una TI seleccionaremos para cada registro, diferentes registros en otras TBD ejecutando la sentencia SELECT SINGLE.
  EJ:
  
• Desde el pto de vista del rendimiento, es una mala practica debido a que si la TI que estamos recorriendo tiene un millón de registros, tendremos que ejecutar si o si un millón de veces los SELECT que están dentro del LOOP.
• Una solución es recuperar en TI, antes del LOOP-ENDLOOP, todos los registros que necesitaremos de las TBD, y luego dentro del LOOP-ENDLOOP aceeder a los mismos en memoria por medio de la sentencia READ TABLE.
  Para hacer esto ejecutaremos la adición FOR ALL ENTRIES dentro del SELECT, en donde se recuperan todos los registros de las TBD a memoria:
  

Evitar usar las sentencias INSERT, UPDATE, MODIFY Y DELETE dentro de un LOOP:

• Estas sentencias mencionadas impactan en las TBD, aplica la misma lógica que vimos en el pto anterior.
  EJ:
  
• No es recomendable acceder a una TBD por medio de un bucle ya que provocaría un problema de rendimiento, el cual puede ser pequeño para una aplicación que recién comienza, pero se puede volver grande cuando esta sea más grande.
• Para evitar usar las sentencias de actualización de TBD dentro de los bucles, debemos trabajar con IT e impactar en las TBD una única vez fuera de los ciclos LOOP-ENDLOOP:
  

SELECT más SELECT vs JOIN:

• Cuando necesitamos seleccionar uno o más TBD, tenemos dos opciones:
  1. Hacer un SELECT a la 1ra TBD y después al hacer el 2do SELECT, implementar la cláusula FOR ALL ENTRIES para usar los registros obtenidos en la 1ra TBD como condición de la selección.
  Pero no es optimo ya que estamos haciendo dos SELECT diferentes cuando podemos optimizar ambos, haciendo una sola selección.
  
  
  2. Podemos hacer un JOIN entre ambas TBD:
  
  Y si es necesario, podemos hacer un JOIN entre tres o más TBD y recuperar en el todos los campos que necesitemos, de esta forma optimizando el rendimiento.

Las buenas y malas practicas en la lógica del procesamiento ABAP:

READ TABLE BINARY SEARCH:

• Cuando leemos un registro de una TI que está en memoria, por la sentencia READ TABLE, el sist. internamente para encontrar el registro que deseamos leer, debe leer secuencialmente todos los registros de la TI, desde el 1ro hasta que llegue al que buscamos.
  EJ:
  
• Existe una alternativa que respecto a la performance es óptima y consiste en ejecutar lo que se denomina una lectura binaria, en lugar de una secuencial.
  Que para ejecutarla tenemos dos condiciones:
  1. La TI tiene que estar ordenada ascendentemente por el campo que deseamos buscar.
  2. Debe agregar la cláusula BINARY SEARCH al final de la sentencia READ TABLE.
  EJ:
  

Evitar hacer un LOOP ENDLOOP dentro de otro:

• EJ:
  
• Pensemos que si la TI 1 tiene almacenados 10.000 registros y la TI 2 tiene otros 10.000, entonces si no se usan condiciones a hacer los ciclos, en el peor de los casos recorreremos 10.000*10.000 registros.
  Podemos mejorar esto si usamos condiciones en el 1er ciclo LOOP-ENDLOOP y por otro lado en lugar de ejecutar el 2do LOOP-ENDLOOP, ejecutamos un READ TABLE con BINARY SEARCH para lo cual previamente debemos ordenar la TI ascendentemente por el campo por los que buscamos un registro.
  EJ:
  

LOOP CHECK vs LOOP WHERE:

Cuando trabajamos con el ciclo LOOP-ENDLOOP tenemos dos opciones para establecer condiciones:

• Escribir las condiciones dentro del LOOP-ENDLOOP, podemos usar la sentencia IF-ENDIF o CHECK para filtrar los registros que procesaremos. Lo malo de esta opción es que no nos evita recorrer o leer cada registro antes de descartarlo.
• Filtrar los registros que procesaremos directamente dentro del LOOP-ENDLOOP especificando una o varias condiciones dentro del WHERE. Esta opción es superior ya que evita recorrer cada registro.
  
• La 2da opción es el doble de performante.

Olvidarnos del WHEN OTHERS en la sentencia CASE:

• Muchas vecemos cuando programemos, podemos olvidarnos del WHEN OTHERS cuando trabajamos con la sentencia CASE-ENDCASE:
  
• Debemos recordar de usar el WHEN OTHERS para siempre tener los resultados que queremos, más si estamos en un ambiente real de trabajo, para no producir errores:
  

APPEND de una TI en otra TI:

• Algo que nos puede pasar es agregar los registros de una TI en otra TI, siendo ambas del mismo tipo. Para llevar a cabo esta lógica podemos:
  1. Recorrer la TI 1 y dentro del LOOP-ENDLOOP hacer un APPEND a cada registro de la TI 2.
  2. Usar la sentencia APPEND LINES OF, en una sola línea para copiar el contenido de una TI a otra.
  
• La 2da opción es 7 veces más performante.

INSERT de una TI a otra TI:

• Nos puede pasar que cuando trabajemos con TI insertemos el contenido de una TI en otra, a partir de determinada posición, siendo ambas tablas del mismo tipo.
  Tenemos dos alternativas:
  1. Recorrer la TI 1 y dentro del LOOP-ENDLOOP hacer un INSERT de cada registro de la TI 2, en determinada posición.
  2. Usar la sentencia INSERT LINES OF, en una sola línea para insertar el contenido de una TI a otra en una posición determinada.
  
• Podemos notar que INSERT LINES OF es 11 veces más performante.

El borrado de registros duplicados de una TI:

• Cuando trabajamos con TI capaz necesitamos borrar registros duplicados de una TI. Tenemos dos opciones, para las cuales necesitamos tener ordenada la TI por el campo por lo que determinaremos si la TI tiene registros duplicados:
  1. Hacer la comparación manualmente, recorriendo cada uno de los registros de la TI y preguntando a cada uno si el registro es igual al anterior, si es así será borrado.
  2. Usar la sentencia DELETE ADJACENT DUPLICATES, la cual borra todos los registros duplicados de un TI, comparando los campos que especificamos luego de COMPARING.
  
• El DELETE ADJACENT DUPLICATES es 8 veces más performante.

Copiar TI:

• Podemos necesitar copiar el contenido de una TI a otra, siendo ambas de igual tipo. Podemos:
  1. Borrar el contenido de la TI 2, luego recorrer la TI 1 y agregar cada registro de la TI 1 a la TI 2.
  2. Usar la asignación tabla_interna_1[ ] = tabla_interna_2[ ], la cual en una sola línea pisa el contenido existente de la TI 1 con el contenido de la TI 2.
  
• Podemos ver que la 2da opción es 38 veces más performante.

Comparación de TI:

• Cuando tengamos que comparar dos TI para poder determinar si su contenido es el mismo en ambas TI, podemos:
  1. Hacer la comparación de las TI manualmente, recorriendo cada TI y leyendo el contenido de la otra TI.
  2. Usar dentro de un IF-ENDIF la asignación tabla_interna_1[ ] = tabla_interna_2[ ], la cual en una sola línea determina si el contenido que existe en la TI 1 es igual al contenido de la TI 2:
  
• La 2da opción es 13 veces más performante.