Reducir el tamaño del código
Cuando es importante reducir el tamaño de una aplicación, hay varias técnicas
que puede aplicar para hacer que el código sea más compacto. Además de reducir
el tamaño de la aplicación en memoria, la mayor parte de estas optimizaciones
también reducirán el tamaño del archivo .exe. Como ventaja adicional, las
aplicaciones pequeñas se cargarán con mayor rapidez.
La mayoría de las técnicas de optimización del tamaño consisten en eliminar
elementos innecesarios del código. Visual Basic elimina automáticamente ciertos
elementos cuando compila la aplicación. No hay razones para restringir la
longitud o el número de los siguientes elementos:
- Identificadores
- Comentarios
- Líneas en blanco
Ninguno de estos elementos afecta al tamaño de la aplicación en memoria
cuando se ejecuta como archivo .exe.
Otros elementos, como las variables, los formularios y los procedimientos,
ocupan espacio en memoria. Normalmente, lo mejor es refinar en esta dirección.
Puede usar varias técnicas para reducir la memoria que ocupa la aplicación
cuando se ejecuta como archivo .exe. Las siguientes técnicas pueden reducir el
tamaño del código:
- Reducir el número de formularios cargados.
- Reducir el número de controles.
- Usar etiquetas en lugar de cuadros de texto.
- Guardar datos en archivos de disco o en otros recursos y cargarlos sólo
cuando sean necesarios. - Organizar los módulos.
- Considerar alternativas al tipo de datos Variant.
- Usar matrices dinámicas y borrarlas para liberar memoria.
- Liberar el espacio utilizado por las cadenas o por las variables de
objeto. - Eliminar el código inservible y las variables que no se utilizan.
Reducir el número de formularios cargadosCada formulario cargado, ya sea visible o no, consume una gran cantidad de
memoria (que varía con el número y el tipo de controles del formulario, el
tamaño de los mapas de bits del formulario, etc.). Sólo cargue los formularios
cuando necesite presentarlos y descárguelos (en vez de ocultarlos) cuando ya no
los necesite. Recuerde que cualquier referencia a las propiedades, los métodos o
los controles de un formulario, o una variable del formulario declarada como
New, hace que Visual Basic lo cargue.
Cuando descarga un formulario mediante el método
Unload, sólo se
libera una parte de la memoria ocupada por el formulario. Para liberar toda la
memoria, invalide la referencia al formulario mediante la palabra clave
Nothing:
Reducir el número de controlesCuando diseña una aplicación, procure usar el mínimo número de controles
posible en los formularios. El límite real depende del tipo de controles y del
sistema disponible, pero en la práctica, los formularios con un gran número de
controles funcionan con lentitud. Una técnica relacionada consiste en usar
matrices de controles siempre que sea posible, en lugar de colocar un gran
número de controles del mismo tipo en el formulario en tiempo de diseño.
Para obtener más información Para aprender más
acerca de las matrices de controles, vea "Trabajar con matrices de controles" en
"Usar los controles estándar de Visual Basic".
Usar etiquetas en lugar de cuadros de textoLos controles
Label utilizan menos recursos de Windows que los cuadros
de texto, por lo que debe usar etiquetas en lugar de cuadros de texto siempre
que sea posible. Por ejemplo, si necesita un control oculto en un formulario
para almacenar texto, es más eficiente usar una etiqueta.
Esta técnica permite optimizar hasta un formulario de entrada de datos que
necesita numerosos campos de texto. Puede crear una etiqueta para cada campo y
usar un único campo de texto para la entrada de campos, desplazándolo hasta la
posición del control
Label siguiente en el evento LostFocus:
Private Sub Label1_LostFocus()
' Actualiza Label1
Label1.Caption = Text1.Text
' Desplaza el control Textbox encima de la etiqueta siguiente
Text1.Move Label2.Left, Label2.Top
' Actualiza el contenido de Text1
Text1.Text = Label2.Caption
End Sub
Puede hacer que una etiqueta se parezca a un cuadro de texto al establecer
las propiedades
BackColor y
BorderStyle. Aunque este técnica
necesita más código, puede reducir de significativamente el uso de los recursos
de un formulario que contiene numerosos campos.
Guardar datos en archivos de disco o en otros recursos y cargarlos sólo
cuando sean necesariosLos datos colocados directamente en la aplicación en tiempo de diseño (como
propiedades o como cadenas literales y números dentro del código) aumentan la
cantidad de memoria consumida por la aplicación en tiempo de ejecución. Puede
reducir la memoria necesaria si carga los datos desde archivos de disco o desde
recursos en tiempo de ejecución. Esto es especialmente útil para los mapas de
bits y las cadenas de gran tamaño.
Organizar los módulosVisual Basic carga los módulos cuando se solicita; es decir, carga un módulo
en memoria solamente cuando el código llama a uno de los procedimientos de ese
módulo. Si nunca llama a un procedimiento de un módulo determinado, Visual Basic
nunca carga dicho módulo. Reunir todos los procedimientos relacionados en el
mismo módulo hace que Visual Basic sólo cargue los módulos cuando son
necesarios.
Considerar alternativas al tipo de datos VariantEl tipo de datos Variant es extremadamente flexible, pero también es mayor en
tamaño que cualquier otro tipo de datos. Cuando tenga que reducir hasta el
último byte de la aplicación, considere la posibilidad de sustituir las
variables Variant, y especialmente las matrices de variables Variant, por otro
tipos de datos.
Cada Variant ocupa 16 bytes, comparado con los 2 bytes de un Integer u 8
bytes de un Double. Las variables String de longitud variable utilizan 4 bytes
más 1 byte por cada carácter de la cadena, pero cada Variant que contiene una
cadena ocupa 16 bytes más 1 byte por cada carácter de la cadena. Como ocupan
tanto, las variables Variant son especialmente problemáticas cuando se utilizan
como variables locales o como argumentos de procedimientos, ya que consumen
rápidamente el espacio de la pila.
Sin embargo, en algunos casos la utilización de otros tipos de datos le
obliga a agregar más código para compensar la pérdida de flexibilidad que
proporciona el tipo de datos Variant, lo que no aporta una reducción neta de
tamaño.
Usar matrices dinámicas y borrado para liberar memoriaPiense en usar matrices dinámicas en lugar de matrices fijas. Cuando ya no
necesite los datos de una matriz dinámica, utilice
Erase o
ReDim
Preserve para descargar los datos innecesarios y liberar la memoria
utilizada por la matriz. Por ejemplo, con el siguiente código puede liberar el
espacio utilizado por una matriz dinámica:
Mientras
Erase elimina completamente la matriz,
ReDim Preserve reduce su tamaño sin perder el contenido:
ReDim Preserve MiMatriz(10, smallernum)
Borrar una matriz de tamaño fijo no libera la memoria ocupada por la matriz,
sino que simplemente borra los valores de los elementos de la matriz. Si los
elementos eran una cadena o variables Variant que contenían cadenas o matrices,
borrar la matriz libera la memoria de esas cadenas o esas variables, no la
memoria ocupada por la matriz.
Liberar el espacio utilizado por las cadenas o por las variables de
objetoEl espacio utilizado por las variables de cadena y de matriz locales (no
estáticas) se libera de forma automática cuando termina el procedimiento. Sin
embargo, las variables de cadena y de matriz globales y de módulo siguen
existiendo durante toda la ejecución del programa. Si intenta mantener la
aplicación con el mínimo tamaño posible, debe liberar el espacio utilizado por
esas variables tan pronto como pueda. Puede liberar el espacio de las cadenas
asignándole cadenas de longitud cero:
SomeStringVar = "" ' Libera el espacio ocupado.
De forma similar, puede liberar parte del espacio (pero no todo) utilizado
por una variable de objeto estableciéndola a
Nothing. Por ejemplo, para
quitar una variable de objeto
Recordset:
Private rs As New RecordSet
… ' Aquí viene código para inicializar y usar un recordset
rs.Close ' Cierra el recordset
Set rs = Nothing ' Establece la referencia al objeto a Nothing
Si no ha establecido explícitamente la referencia del objeto a Nothing,
permanecerá su referencia en memoria hasta que la aplicación termine; para una
aplicación que utiliza muchos objetos podría consumir la memoria disponible y
bajar el rendimiento de la aplicación.
Puede también recuperar el espacio mediante la descarga de formularios y
estableciéndolos a Nothing en lugar de ocultarlos cuando no se necesiten
más.
Eliminación del código inservible y las variables que no se utilizanAl desarrollar y modificar las aplicaciones, puede dejar
código
inservible; es decir, procedimientos enteros a los que no se llama desde
ninguna parte del
código. También puede haber variables declaradas que
después no se utilizan. Aunque Visual Basic quita las constantes que no se
utilizan, no quita las variables que no se utilizan ni el
código inservible
cuando crea un .exe. No olvide repasar el
código para buscar y quitar
los procedimientos y las variables que no se utilicen. Por ejemplo, las
instrucciones
Debug.Print, aunque se pasan por alto en tiempo de
ejecución, se encuentran presentes en el archivo .exe.
Las instrucciones
Debug.Print con cadenas o variables como argumentos
no se compilan cuando se crea un .exe. Sin embargo, cuando las instrucciones
Debug.Print tienen una llamada a una función como argumento, el
compilador ignora la instrucción
Debug.Print, pero la llamada a la
función se compila. Más tarde, cuando se ejecuta la aplicación, se llama a la
función pero se pasa por alto su resultado. Como las funciones que aparecen como
argumentos de
Debug.Print ocupan espacio y tiempo de CPU, puede ser
conveniente eliminar estas instrucciones antes de generar un .exe.
Utilice el comando
Buscar del menú
Edición para buscar
referencias a una variable concreta. Si tiene instrucciones
Option
Explicit en todos los módulos, puede determinar cuándo la aplicación utiliza
una variable si la quita o si pone como comentario su declaración y ejecuta
después la aplicación. Si se utiliza la variable, Visual Basic generará un
error. Si no recibe ningún error, la variable no se usará.
Para obtener más información Para aprender más
acerca de la instrucción
Debug.Print, vea "Imprimir información en la
ventana Inmediato" en "Depurar el código y tratar errores".