Uso correcto de los tipos de datos

El uso de la memoria y el procesamiento van a depender de los tipos de datos que utilicemos en nuestros programas y de las opciones con que estos datos son compilados.

A continuación detallamos que tipos de datos en COBOL son más eficientes y como influyen en ello diferentes opciones de compilación.

BINARY (COMP o COMP-4)

Las consideraciones generales de eficiencia cuando utilizamos la declaración PICTURE S9(n) COMP son:

OPCION	N	Eficiencia
*TRUNC(STD)*	*1-8*	*La más rápida*
	9-10	Un 10 % más lenta que de 1-8
	10-17	Un 230 % más lenta que de 1-8
	18	Un 450% más lenta que de 1-8
*TRUNC(OPT)*	*1-8*	*Es la más rápida*
	9-10	Un 40 % más lenta que de 1-8
	10-17	Un 25 % más lenta que de 1-8
	18	Un 115 % más lenta que de 1-8
*TRUNC(BIN)*	*1-4*	*La más rápida*
	5-9	Un 45 % más lenta que de 1-4
	10-18	Un 3015 % más lenta que de 1-4

COMP-5

Los datos binarios de tipo COMP-5 son similares a los anteriores BINARY o COMP-4 con la excepción de que siempre se comportan como si la opción TRUNC(BIN) estuviera seleccionada para ellos.

OPCION	N	Eficiencia
*TRUNC(STD)* *TRUNC(OPT)* *TRUNC(BIN)*	*1-4*	*La más rápida*
	5-9	Un 30 % más lenta que de 1-4
	10-18	Un 3020 % más lenta que de 1-4

Las conversiones entre diferentes formatos de datos a un formato común son necesarias cuando se realizan cálculos con diferentes tipos de datos. Esto implica tiempo adicional de procesamiento y almacenamiento para estas conversiones.

DISPLAY

Evite utilizar los datos con USAGE DISPLAY para realizar cálculos, especialmente en áreas donde tengan un uso intensivo. Los datos con USAGE DISPLAY obligan a realizar operaciones de conversión antes y después de utilizar el tipo de dato. Esto implica una llamada a una rutina interna de la librería de COBOL que podíamos ahorrárnosla si utilizamos el dato apropiado que no requiera conversión.

OPCION	N	Eficiencia
*ARITH(COMPACT)*	*1-15*	*La más rápida con un número par de dígitos*
	2-16	Un 20 % más lenta con un número impar de dígitos que el caso anterior
	17-18	Un 70-90 % más lenta que de 1-15 dígitos con un número par de dígitos
*TRUNC(EXTEND)*	*1-15 ó de 19-31*	*La más rápida con un número par de dígitos*
	2-16 ó 20-30	Un 20 % más lenta usando un número impar de dígitos que en el caso anterior
	17-18	Es un 70-90% más lenta con un número par de dígitos que el caso anterior

PACKED-DECIMAL (COMP-3)

Cuando se utilicen datos de tipo COMP-3 en cálculos hay que intentar utilizar entre 1-15 dígitos. Números con más de 15 dígitos implican que las operaciones de multiplicación o división necesitan llamar a una rutina extra que influye en la velocidad en que se realizan los cálculos.

Adicionalmente se tiene un resultado mucho más eficiente con datos COMP-3 con signo y un número par de dígitos.

OPCION	N	Eficiencia
*ARITH(COMPACT)*	*1-15*	*La más rápida con un número par de dígitos (10-30% más rápida con que un número impar de dígitos)*
*ARITH(COMPACT)*	16-18	Un 150 % más lenta que el caso anterior
*TRUNC(EXTEND)*	*1-15*	*La más rápida con un número par de dígitos (5-30% más rápida con que un número impar de dígitos)*
*TRUNC(EXTEND)*	16-31	Un 150 % más lenta que el caso anterior

Selección de los tipos de datos apropiados

Cuando se seleccionan los tipos de datos, no solo hay que tener en cuenta el tipo lógico (de caracteres, numéricos, etc.) para el dato que van a acomodar, sino también el tamaño del dato y las consideraciones de eficiencia.

Los dos primeros aspectos dependen más de la habilidad del programador y de la naturaleza del requerimiento que se está programando.

No obstante, tiene siempre que primar el criterio de eficiencia. Si vamos a guardar un nombre de usuario de 8 caracteres no hace falta un PIC X(50) sino un PIC X(8).

En ocasiones, los programadores dedican más espacio ante la imposibilidad de preveer el futuro crecimiento de un dato. Por ejemplo si un dato es el nombre o apellidos de un usuario, es muy difícil preveer entre nombres cortos o largos o compuestos, como Iván o José Manuel (en un caso nos bastarían 4 caracteres y en otro 11). Lo más lógico es encontrar un tamaño razonable como un PIC X(25) que podría acomodar la mayoría de los nombres y apellidos compuestos en español.

Decimal empaquetado (COMP-3) vs. binario (COMP o COMP-4) con TRUNC(STD)
1-9 dígitos	COMP-3 es 40-80% más lento
10-17 dígitos	COMP-3 es 10-50% más rápido
18 dígitos	COMP-3 es un 70% más rápido
Decimal empaquetado (COMP-3) vs. binario (COMP o COMP-4) con TRUNC(OPT)
1-8 dígitos	COMP-3 es 200-450% más lento
9 dígitos	COMP-3 es 100% más lento
10-17 dígitos	COMP-3 es 200-500% más lento
18 dígitos	COMP-3 es un 40% más rápido
Decimal empaquetado (COMP-3) vs. binario (COMP o COMP-4) con TRUNC(BIN) o COMP-5
1-8 dígitos	COMP-3 es 200-400% más lento
9 dígitos	COMP-3 es 85% más lento
10-18 dígitos	COMP-3 es un 70-86% más rápido
DISPLAY vs. Decimal empaquetado (COMP-3)
1-6 dígitos	DISPLAY es un 50% más lento
7-16 dígitos	DISPLAY es un 40% más lento
17-18	DISPLAY es 100% más lento
DISPLAY vs. binarios (COMP o COMP-4) con TRUNC(STD)
1-8 dígitos	DISPLAY es un 50%-80% más lento
9 dígitos	DISPLAY es un 40% más lento
10-16 dígitos	DISPLAY es 30-50% más rápido
17 dígitos	DISPLAY es un 10% más rápido
18 dígitos	DISPLAY es un 40% más rápido
DISPLAY vs. binarios (COMP o COMP-4) con TRUNC(OPT)
1-8 dígitos	DISPLAY es un 200%-400% más lento
9 dígitos	DISPLAY es un 150% más lento
10-16 dígitos	DISPLAY es 200-400% más lento
17 dígitos	DISPLAY es 500% más lento
18 dígitos	DISPLAY es un 40% más rápido
DISPLAY vs. binarios (COMP o COMP-4) con TRUNC(BIN) o COMP-5
1-4 dígitos	DISPLAY es un 200%-400% más lento
5-9 dígitos	DISPLAY es un 200-250% más lento
10-18 dígitos	DISPLAY es 70-85% más rápido

Aritmética de punto fijo contra punto flotante

Cuando se trata de mejorar el rendimiento de una aplicación, hay que determinar cuidadosamente cuando utilizamos aritmética de punto fijo y de punto flotante.

Cuando hacen falta conversiones, los datos de tipo decimales empaquetados (COMP-3) o binarios con 9 dígitos o menos, generan una sobrecarga cuando son convertidos a o desde datos de punto flotante (COMP-1 o COMP-2).

Además cuando se utilizan exponentes muy grandes, la operación es más eficiente si es forzada completamente a punto flotante:

01 A PIC S9(6)V9(12) COMP-3 VALUE 0.

01 B PIC S9V9(12) COMP-3 VALUE 1.234567891.

01 C PIC S9(10) COMP-3 VALUE -99999.

COMPUTE A = (1 + B) ** C. (original)

COMPUTE A = (1.0E0 + B) ** C.(forzada)

En este ejemplo hemos forzado el cálculo a punto flotante mediante el cambio de la constante en punto fijo 1 a la constante en punto flotante 1.0E0.

Como consideración de rendimiento, una operación de exponenciación es un 98% más rápida en punto flotante que en punto fijo.

Índices de tablas

El uso de índices para direccionar a una tabla, es mucho más eficiente que utilizar otro tipo de variable. Esto se debe a que los índices ya contienen el desplazamiento en la memoria calculado desde el comienzo de la tabla y no este no tiene que ser vuelto a calcular en tiempo de ejecución.

Los índices de tabla son definidos por la cláusula INDEXED BY en la cláusula OCCURS para un tipo de dato.

El uso de otras variables implica que primero hay que convertir su valor en un desplazamiento para luego poder acceder a los datos de la tabla.

Si es necesario utilizar variables diferentes a los índices para acceder a una tabla, utilice datos de tipo binario con signo (COMP) con 8 ó menos dígitos. Esto permitirá el uso de aritmética entera fullword durante los cálculos y en algunos casos el uso de 4 dígitos o menos generará aritmética halfword aún más rápida.

Las consideraciones de rendimiento en este caso con un PIC S9(8) son:

El uso de datos binarios (COMP) para direccionar una tabla es un 40% más lento que los índices
El uso de decimales empaquetados (COMP-3) para direccionar una tabla es un 220% más lento que los índices
El uso de datos con USAGE DISPLAY es un 300% más lento que el uso de índices

OCCURS DEPENDING ON

En COBOL podemos tener tablas de longitud variable cuyo tamaño es calculado en tiempo de ejecución a partir del valor de una variable.

01 MES
01 SEMANA.
02 VISTAS

PIC 99.

PIC 9(4) OCCURS 28 TO 31 DEPENDING OF MES.

Lo más óptimo sería:

01 MES
01 SEMANA.
02 VISTAS

PIC 99 COMP.

PIC 9(4) COMP OCCURS 28 TO 31

DEPENDING OF MES.

De esta manera nos evitamos conversiones extras cada vez que se haga referencia a la longitud de la tabla o sus elementos.

De manera general:

El uso de tablas de longitud variable es un 5% más lento que las tablas de longitud fija
Cuando se usan tablas de longitud variable la referencia al primer elemento complejo es un 9% más lenta que en tablas de longitud fija
Cuando se usan tablas de longitud variable la referencia a cualquier elemento complejo diferente del primer elemento es un 150% más lenta que en tablas de longitud fija

Variables de control de bucles

Cuando se utiliza la sentencia PERFORM VARYING, si utilizamos una variable de control tipo DISPLAY, la misma tiene que ser convertida a un tipo de datos COMP antes de ser evaluada provocando una demora que puede ser significativa cuando tenemos miles o millones de datos o incluso varios bucles anidados.

Las consideraciones de rendimiento para variables de control de bucles tipo PIC S9(8) son:

El uso de COMP-3 es un 250% que el uso de COMP
El uso de DISPLAY es un 400% que el uso de COMP

Búsquedas

Cuando se utiliza la instrucción SEARCH, hay que poner los datos usados con más frecuencia en las primeras posiciones de la tabla para optimizar las búsquedas secuenciales.

Para obtener mejores rendimientos, especialmente en tablas muy grandes conviene que los datos están previamente ordenados y se utilice la sentencia SEARCH ALL (búsqueda binaria).

Las consideraciones generales de rendimiento son:

Usar la búsqueda binaria (SEARCH ALL) para tablas de 100 elementos, es un 15% más rápido que la búsqueda secuencial (SEARCH)
Usar la búsqueda binaria (SEARCH ALL) para tablas de 1000 elementos, es un 500% más rápido que la búsqueda secuencial (SEARCH)
El tamaño de la tabla afecta directamente el rendimiento de la búsqueda. Las búsquedas en tablas muy grandes se hacen mejores de forma binaria

Conversión de caracteres

Cuando se convierte a mayúsculas o minúsculas un conjunto de caracteres, es generalmente más eficiente el uso de INSPECT CONVERTING que el uso de las funciones predefinidas FUNCTION UPPER-CASE o FUNCTION LOWER-CASE.

Adicionalmente estas funciones usan almacenamiento temporal en la pila, que la sentencia INSPECT no utiliza. Esta cantidad extra depende del tamaño de la cadena o dato de caracteres a convertir.

Las consideraciones de rendimiento son:

En una prueba en la que se realizaron 1000 conversiones a mayúsculas, fue un 35% más eficiente el uso de INSPECT CONVERTING que el uso de FUNCTION UPPER-CASE.
En esta misma prueba, se utilizó un 70% más de memoria que el uso de INSPECT CONVERTING

Inicializando datos

La sentencia INITIALIZE inicializa conjunto de datos a sus valores predeterminados. Su funcionalidad es equivalente al uso de uno o más sentencias MOVE.

Sin embargo es ineficiente inicializar toda una estructura de datos, a menos que todos sus miembros necesiten tener su valor predeterminado.

Si en la estructura de datos hay una cláusula OCCURS es más eficiente utilizar MOVE si queremos inicializar todos los miembros del conjunto a un mismo carácter (por ejemplo espacio o X’00).

Las consideraciones de rendimiento para un programa que tiene cinco OCCURS en un grupo son:

Cuando cada OCCURS en el grupo tenía 100 elementos, un MOVE al grupo fue un 8 % más rápido que un INITIALIZE al grupo
Cuando cada OCCURS en el grupo tenía 1000 elementos, un MOVE al grupo fue un 23 % más rápido que un INITIALIZE al grupo

posted under Arquitectura, COBOL, IBM, Mainframe |

Jose Manuel Ayala Wilson