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
|
Conversiones de datos
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)
|
|
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)
|
|
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
Recent Comments