Por: Fernando D. Bozzo
Este es un artículo de una serie que se enfocará en técnicas de programación y optimización en distintas áreas.
Un
buen desarrollador asimilará estas técnicas como parte de su forma de
trabajo habitual, independientemente de que haga un sistema, ún módulo,
una rutina o un programa de pruebas personales, ya que le
permitirá programar siempre orientado a la eficiencia, la velocidad de
ejecución, la encapsulación, la reutilización y la legibilidad y mantenibilidad del código, o sea, las buenas prácticas.
Al tener en cuenta estas técnicas en cada parte del código y en cada rutina, al final lo que se logra es que el sistema completo esté más optimizado porque sus partes lo están.
Una de las operaciones más costosas a nivel de recursos en una PC es
la de accesos al disco, ya que el disco es probablemente el componente
más lento del sistema. Aunque los discos SSD minimizan el problema, la
solución real pasa por la programación, ya que tanto los discos rígidos y
sobre todo las redes, son los principales cuellos de botella.
Muchas veces un programa o un sistema comienza teniendo un
único usuario o unos pocos, pero puede que con el tiempo esa condición
cambie, y que comiencen a haber más usuarios, incluso muchos usuarios, y
es aquí cuando comienzan a verse realmente los problemas de las decisiones de diseño tomadas y donde ya es
tarde para cambiarlo por el esfuerzo que puede requerir, implicando a veces un rediseño, por eso cada línea de código cuenta.
Optimizaciones en el uso de archivos y accesos a disco
Caso 1: Los LOGs
Normalmente, cuando se quiere hacer un log al disco de alguna información importante para nosotros o para su posterior explotación o análisis, se suele usar STRTOFILE() por comodidad o por falta de tiempo. He aquí algunos ejemplos típicos:
1.a) Ejemplo de un LOG dentro de un
bucle que puede tener cualquier cantidad de registros:
SCAN FOR <condición>
...
IF <condicion_que_requiere_loguear>
STRTOFILE( 'alguna información importante', 'LOG.txt', 1 )
ENDIF
ENDSCAN |
1.b) Ejemplo de un LOG en un evento
Timer que podría ejecutarse varias veces por segundo:
PROCEDURE TIMER
...
IF <condicion_que_requiere_loguear>
STRTOFILE( 'alguna información importante', 'LOG.txt', 1 )
ENDIF
ENDPROC |
1.c) Ejemplo de un LOG en un
método de cálculo reutilizable, que podría llamarse cientos de veces desde distintas partes de un sistema:
PROCEDURE Sumar_Porcentaje
...
IF <condicion_que_requiere_loguear>
STRTOFILE( 'alguna información importante', 'LOG.txt', 1 )
ENDIF
ENDPROC |
1.d) Ejemplo de un LOG en un
método de proceso largo, donde se realizan diversas operaciones y por cada una se va actualizando el LOG:
PROCEDURE Proceso_Largo
<operación-1>
STRTOFILE( 'alguna información importante', 'LOG.txt', 1 )
<operación-2>
STRTOFILE( 'alguna información importante', 'LOG.txt', 1 )
...
<operación-n>
...
ENDPROC |
En todos los casos, STRTOFILE() escribirá al disco para ir añadiendo información al LOG. Para unas pocas repeticiones esto puede no ser un problema, pero siempre hay que asumir un caso de uso desfavorable, en este caso intensivo.
Veamos qué ocurre cuando la repetición es de 100 iteraciones:
- Para 1 usuario implicará 100 accesos a disco
- Para 5 usuarios implicará 500 accesos a disco
- Para 10 usuarios implicará 1000 accesos a disco
Puede verse que el impacto se multiplica rápidamente a medida que crece la cantidad de usuarios, lo que puede causar que el sistema de archivos se vaya poniendo cada vez más lento por la metralla de escrituras, pudiendo llegar incluso a no dar abasto en responder las peticiones y provocar el colapso del sistema.
Otro error común al escribir LOGs es que se suele elegir un nombre (ej: LOG.txt) y se olvida el hecho de que esto puede ser usado por varios usuarios concurrentes, lo que puede provocar la de
contención de recursos porque dos ó más personas intentan usar el mismo archivo con el mismo nombre; también puede provocar
errores, en el caso de que el LOG se use en exclusiva (con FOPEN/FWRITE) o también puede provocar
pérdida de información de partes del LOG, ya que mientras un usuario está escribiendo en el LOG, otro no puede hacerlo y STRTOFILE() simplemente no escribe y tampoco generará un error por ello (STRTOFILE solo devuelve la cantidad de bytes escritos, 0 en caso de no poder escribir, pero nadie suele verificar esto)
Soluciones
Para resolver el problema de los usuarios concurrentes, se puede usar un LOG distinto por usuario, que puede tener una numenclatura parecida a "LOG_UsuarioDeRed.txt", o una más completa como "LOG_UsuarioDeRed_NombreMaquina.txt". Si se quiere un historial de LOGs diarios, se podría agregar la fecha al nombre del LOG. Como se ve, variantes hay para todos los gustos.
Para minimizar el impacto de estas escrituras se suele usar la estrategia del buffering (o caché), que implica ir guardando la información que se quiere escribir en una variable de memoria o una propiedad y cada tanto realizar la escritura de todo lo guardado. En este caso hay varias alternativas, que van desde un objeto LOG que autogestione la cantidad de texto que puede guardar para hacer escrituras automáticas al llegar a cierto tamaño acumulado, o a algo más sencillo y práctico como hacer dos métodos, uno de escritura en buffer y uno de flush al disco, que es la técnica que usé en FoxBin2Prg y que muestro a continuación, simplificado y adaptado para el ejemplo:
DEFINE CLASS C_LOG
#DEFINE CR_LF CHR(13)+CHR(10)
c_TextoLog = ''
c_LogFile = ''
PROCEDURE Init
c_LogFile = ADDBS( SYS(2023) ) + 'LOG_' ;
+ CHRTRAN( SYS(0), ' ', '_' ) + '.TXT'
ENDPROC
PROCEDURE Destroy
THIS.writeLog_Flush()
ENDPROC
PROCEDURE writeLog
LPARAMETERS tcText
TRY
WITH THIS
.c_TextoLog = .c_TextoLog + EVL(tcText,'') + CR_LF
ENDWITH
CATCH && En este caso no me interesa reportar errores
ENDTRY
ENDPROC
PROCEDURE writeLog_Flush
WITH THIS
IF NOT EMPTY(.c_TextLog)
STRTOFILE( .c_TextLog + CR_LF, .c_LogFile, 1 )
ENDIF
.c_TextLog = ''
ENDWITH
ENDPROC
ENDDEFINE |
En el ejemplo, en el
Init() se define en nombre del LOG, luego se usa el método
writeLog() para escribir el texto que se quiera en la propiedad c_TextoLog y a la que se agrega un fin de línea, y finalmente el método
writeLog_Flush() que se encarga de escribir al disco todo el texto acumulado y de vaciar la propiedad que lo acumula. Cuando se descarga la clase, también se escribe automáticamente al disco lo que quede por escribir.
Este es un método muy simple y efectivo que permite sustituir los STRTOFILE() de los ejemplos anteriores por
writeLog() y que solo requiere ubicar las llamadas a
writeLog_Flush() fuera de los bucles de repetición o de las rutinas de uso frecuente, pero siempre teniendo en cuenta que en puntos estratégicos debe ser ejecutado, para evitar que el LOG se acumule indefinidamente y cause problemas de memoria.
Usando esta técnica, las escrituras al disco o por la red se pueden minimizar de forma muy notoria, y lograr que el sistema siga siendo responsivo.
Caso 2: Actualización de TABLAS
En Fox, una de las cosas que más se usa son las tablas y los cursores, tanto para guardar datos como para guardar información temporal de proceso, ya que Fox está optimizado para eso a tal punto que manejar un cursor de un millón de registros es más rápido que manejar un array de la misma cantidad de filas.
Pero esta orientación a datos muchas veces no es bien implementada, y es muy común encontrarse con código como este:
DO WHILE <condición>
...
REPLACE campo1 WITH valor1
REPLACE campo2 WITH valor2
REPLACE campo3 WITH valor3
REPLACE campo4 WITH valor4
REPLACE...
...
ENDDO |
Al igual que en el Caso 1, si este bucle se repite en 100
iteraciones y usando solo 5 REPLACE:
- Para 1 usuario implicará 500 accesos a disco
- Para 5 usuarios implicará 2500 accesos a disco
- Para 10 usuarios implicará 5000 accesos a disco
Puede notarse que en este caso todavía es peor que en el anterior, ya
que muchos están acostumbrados a poner varios REPLACE en sucesión, por
motivos como que "es más fácil para copiar" o simplemente porque les
gusta verlos separados...
Esta es otra variante bastante común que se puede encontrar, donde es necesario hacer REPLACE solo bajo ciertas condiciones y muchos lo implementan así:
SCAN FOR <condición>
...
IF <cond.1>
REPLACE campo1 WITH valor1
ENDIF
IF <cond.2>
REPLACE campo2 WITH valor2
ENDIF
IF <cond.3>
REPLACE campo3 WITH valor3
ENDIF
IF <cond.4>
REPLACE campo4 WITH valor4
ENDIF
IF ...
REPLACE...
...
ENDSCAN |
La única diferencia con el caso anterior, es que en cada iteración la cantidad de reemplazos no es fija porque depende de condiciones, pero como siempre, hay que ubicarse en el peor caso donde todas las condiciones puedan ser verdaderas, por lo que en este caso se puede llegar a los mismos 5 REPLACE del ejemplo anterior y a las mismas estadísticas de accesos a disco por usuario.
La realidad es que tanto esta como la otra son malas prácticas y deben evitarse a toda costa, porque penalizan mucho el rendimiento, y más en una red.
Soluciones
Básicamente las soluciones pasan por realizar estos reemplazos en una sola operación, y estas técnicas sirven para cubrir ambos casos con mucha facilidad, como puede verse en los siguientes ejemplos.
Ejemplo 1: Usando un objeto de registro
DO WHILE <condición>
...
SCATTER NAME loReg && o SCATTER FIELDS para más precisión
loReg.campo1 = valor1
loReg.campo2 = valor2
loReg.campo3 = valor3
loReg.campo4 = valor4
loReg.campoN...
GATHER NAME loReg && Un único reemplazo
...
ENDDO |
Ejemplo 2: Usando variables
SCAN FOR <condición>
...
lc_campo1 = valor1
lc_campo2 = valor2
lc_campo3 = valor3
lc_campo4 = valor4
lc_campoN...
REPLACE campo1 WITH lc_campo1 ;
, campo2 WITH lc_campo2 ;
, campo3 WITH lc_campo3 ;
, campo4 WITH lc_campo4 ;
, campoN WITH lc_campoN && Un único REPLACE para todos
...
ENDSCAN |
Ejemplo 3: Usando un array
SCAN FOR <condición>
...
SCATTER TO ARRAY laReg && o SCATTER FIELDS para más precisión
laReg(1) = valor1
laReg(2) = valor2
laReg(3) = valor3
laReg(4) = valor4
laReg(N)...
GATHER FROM laReg && Un único reemplazo
...
ENDSCAN |
Y para reemplazos condicionados se puede usar el mismo código de los ejemplos, solo que condicionando las asignaciones de las variables o propiedades.
El caso anterior fue para reemplazos de datos existentes, pero para registros nuevos es lo mismo, con la salvedad de que como primera opción más recomendable se agrega el Insert-SQL:
Ejemplo 1: Usando Insert-SQL para un registro
SCAN FOR <condición>
...
SCATTER BLANK NAME loReg
loReg.campo1 = valor1
loReg.campo2 = valor2
loReg.campo3 = valor3
loReg.campo4 = valor4
loReg.campoN...
INSERT INTO <tabla> FROM NAME loReg
...
ENDSCAN |
Ejemplo 2: Usando Insert-SQL para varios registros
SCAN FOR <condición>
...
DIMENSION laReg(3,5)
laReg(1,1) = valor1
laReg(1,2) = valor2
laReg(1,3) = valor3
laReg(1,4) = valor4
laReg(1,5...
...
INSERT INTO <tabla> FROM laReg
...
ENDSCAN |
Otra variante es usar un cursor con la misma estructura que la tabla, realizar los Inserts en el cursor y luego volcarlo en la tabla.
Como se puede ver opciones hay muchas, y cada una puede ser más óptima que la otra dependiendo de nuestras necesidades o de cómo queramos implementarlo, pero para el buffering en memoria podemos usar tanto variables como cursores, pudendo incluso usar buffering de tablas o registros mediante CursorSetprop().
Nota: En el caso de usar cursores o buffering de tablas o registros, recordar cada tanto usar la función SYS(1104) para liberar los buffers de memoria. Como ejemplo, cada 100 registros reemplazados se podría forzar la limpieza de los buffers para liberar memoria.
Caso 3: Escritura de grandes cantidades de texto (>1 MB y <= 2 GB)
Hay situaciones en las que tenemos un proceso que requiere ir generando información al disco en formato texto. La diferencia con un LOG, como vimos al inicio, es que un LOG puede desactivarse o condicionarse, mientras que en este caso hablamos de un proceso que sí o sí debe escribir al disco para generar un archivo de texto en múltiples pasos o subprocesos. Un ejemplo de este tipo de proceso puede ser un parser o un conversor, donde se va interpretando el origen de datos (o un archivo origen) y a la vez se va generando la información de salida a un archivo de texto.
Si bien la primera reacción puede ser la de usar la técnica del buffering del Caso 1 mediante el uso de una variable o una propiedad acumuladora, es necesario saber que para textos superiores a 1 MB FoxPro se empieza a poner lento, principalmente por la acumulación en una variable que va creciendo y que además va consumiendo cada vez más memoria.
En estos casos, lo más óptimo es usar funciones de bajo nivel como FOPEN/FWRITE con buffering, lo que da una velocidad que como mínimo duplica al buffering por variable o propiedad acumulada.
Aunque pueda parecer contradictorio decir que una función de manejo de archivos de bajo nivel sea más rápida en estos casos que una variable, la explicación está en que no solo Fox no se maneja bien con variables con mucho contenido que se actualiza constantemente, sino que además las funciones de manejo de archivos a bajo nivel con uso de buffering están optimizadas para justamente para no escribir todo el tiempo al disco, sino que implementan su propio esquema de buffering.
Caso 4: Generación de texto con TEXT/ENDTEXT
No se puede hablar de generación de texto sin hablar de TEXT/ENDTEXT, que es uno de los comandos más potentes y versátiles de FoxPro desde los inicios, pero primero veamos un ejemplo de la salida que queremos conseguir:
Fecha: 01/05/2015 Fernando Caimo
Número de viajes: 30
Kilómetros hechos: 275
------------------------------------------------------------
|
Así es cómo se puede generar este texto usando variables y contenido dinámico:
cTexto = ''
cTexto = cTexto + chr(13)+chr(10)
cTexto = cTexto + 'Fecha: ' + dtoc(date()) + space(20) ;
+ cApellidoYNombre + chr(13)+chr(10)
cTexto = cTexto + chr(13)+chr(10)
cTexto = cTexto + 'Número de viajes: ' + TRANSFORM(nViajes) ;
+ chr(13)+chr(10)
cTexto = cTexto + 'Kilómetros hechos: ' + TRANSFORM(nKM) ;
+ chr(13)+chr(10)
cTexto = cTexto + chr(13)+chr(10)
cTexto = cTexto + replicate('-', 60)
|
Y esta es la forma en que se hace con TEXT/ENDTEXT:
TEXT TO cTexto ADDITIVE TEXTMERGE NOSHOW FLAGS 1+2 PRETEXT 1+2
Fecha: <<date()>> <<cApellidoYNombre>>
Número de viajes: <<nViajes>>
Kilómetros hechos: <<nKM>>
------------------------------------------------------------
ENDTEXT |
....no hay contraste! TEXT/ENDTEXT es tan increíblemente versátil y claro para generar este tipo de documentos que deja en vergüenza al resto de métodos disponibles.
Pero tanta potencia tiene sus casos de uso y su coste, por lo que tampoco es cuestión de usarlo para cada línea de texto que se quiera generar, y es que para líneas individuales, y más si se usa de la siguiente forma, no es recomendable:
FOR X=1 TO loProcedure._ProcLine_Count
TEXT TO lcMemo ADDITIVE TEXTMERGE NOSHOW FLAGS 1+2 PRETEXT 1+2
<<loProcedure._ProcLines(X)>>
ENDTEXT
ENDFOR
STRTOFILE(lcMemo, 'salida.txt', 1)
|
Como puede verse, aunque la parte de escritura con STRTOFILE está optimizada porque está fuera del bucle, lo que de por sí impactará poco en accesos a disco, el TEXT/ENDTEXT está en un bucle de repetición cuya iteración puede ser alta, y el problema con este caso en particular es que por cada línea que se genera y agrega a lcMemo, se requiere inicializar una estructura de parseo, parsear cada uno de los parámetros indicados y luego procesar el texto entre TEXT y ENDTEXT usando los parámetros indicados. Y todo esto para una línea en un bucle es demasiado coste para la CPU.
En su lugar, y para este caso particular, lo más conveniente y óptimo es usar una variable:
FOR X=1 TO loProcedure._ProcLine_Count
lcMemo = lcMemo + chr(13)+chr(10) + loProcedure._ProcLines(X)
ENDFOR
STRTOFILE(lcMemo, 'salida.txt', 1) |
Resumen
El objetivo siempre debe ser hacer el código más óptimo para cada situación, y en el caso de los archivos siempre se trata de minimizar los accesos a disco usando técnicas de buffering.
Lo que se logra con estas técnicas, específicamente, es:
- Menor cantidad de accesos a disco (o red)
- Menor uso de recursos del sistema
- Disminución de posibilidades de contención
- Mayor velocidad de proceso
- Alargamiento de la vida útil de los discos, tanto rígidos como SSD
Puede que hayan quedado fuera algunas cosas, pero quería hacer un resumen con algunas de las más importantes a tener en cuenta.
Hasta la próxima! :D
