Mensajes

[Optimizar Aplicaciones (Segunda Parte)]

Optimizar Aplicaciones (Segunda Parte)

Modificadores del compilador para código nativo

Microsoft Visual Basic permite compilar las aplicaciones a código nativo rápido y eficiente mediante la misma tecnología de optimización de compilación que Microsoft Visual C++. La compilación a código nativo proporciona varias opciones de optimización y depuración que no se encuentran disponibles en el p-code. Estas opciones se conocen tradicionalmente como "modificadores", porque cada opción puede estar activada o desactivada.

En este apéndice se documentan las opciones del compilador para código nativo, que aparecen en la ficha Compilar del cuadro de diálogo Propiedades del proyecto, disponible en el menú Proyecto. Para obtener más información acerca del código nativo, vea "Compilar proyectos a código nativo" en "Detalles de programación".

Textos Extraidos de las Librerías de Microsoft Developer NetWork.

Dudas, comentarios, aclaraciones y consultas en otro hilo, en otro tema, en otra publicación, en otro post.

Comentario: No te aflijas si crees que, además de ser mucho, puede resultar demasiado laborioso de aprender. Esto más que nada se adquiere con el paso del tiempo y los programas que vallas desarrollando, de modo que toda esta documentación viene siendo una referencia.

Hilsener.

[Compatibilidad con otras aplicaciones de Microsoft]

Compatibilidad
con otras aplicaciones de Microsoft

Visual Basic es el miembro superior de la familia de productos Visual Basic,
que incluye Visual Basic para aplicaciones y Visual Basic, Scripting Edition
(VBScript). Si bien puede compartir la mayor parte del código que escriba en
Visual Basic con aplicaciones escritas en Visual Basic para aplicaciones o
VBScript, hay algunas excepciones.


Compatibilidad con Visual Basic para aplicaciones

Visual Basic para aplicaciones es un único entorno y lenguaje de escritura de
comandos que los usuarios y los programadores pueden compartir entre sus
escritorios de Windows. Visual Basic para aplicaciones se incluye en Microsoft
Office y en otras aplicaciones de Microsoft. También se ha autorizado su uso a
otros fabricantes de software y se incluye en una variada gama de productos.
Visual Basic para aplicaciones, contenido en Vba6.dll, es el motor de
lenguaje de Visual Basic. Esta biblioteca contiene todos los elementos del
lenguaje compartidos por Visual Basic para aplicaciones y Visual Basic. Puede
ver los elementos si selecciona VBA en el cuadro de lista Biblioteca del
Examinador de objetos. El código escrito en Visual Basic para aplicaciones es
portátil a Visual Basic con las siguientes limitaciones: el código de Visual
Basic para aplicaciones que hace referencia a elementos específicos de la
aplicación (como una hoja de trabajo de Microsoft Excel) se puede transportar,
siempre y cuando contenga una referencia completa y que la aplicación exista en
la máquina de destino.

Los elementos específicos de Visual Basic, como los formularios y los
controles intrínsecos, se encuentran en la biblioteca de tipos Vb6.olb (también
visible en el Examinador de objetos). En general, el código escrito en Visual
Basic es portátil a Visual Basic para aplicaciones mientras no haga referencia a
estos elementos.

Para obtener más información   Para aprender más
acerca de Visual Basic para aplicaciones, visite el sitio Web de Microsoft en
http://www.microsoft.com/spanish. Para aprender más acerca de las referencias a
objetos, vea "Crear una referencia a un objeto" en "Programar con componentes".
Para aprender más acerca de la compilación a código nativo, vea "Compilar
proyectos a código nativo" en "Detalles de programación".


Compatibilidad con Visual Basic Scripting Edition

Visual Basic Scripting Edition (VBScript) está diseñado para incorporarlo a
un explorador de Internet, como Microsoft Internet Explorer u otros
exploradores. VBScript es un motor de lenguaje ligero y extremadamente rápido
diseñado específicamente para entornos como Internet, redes internas (intranets)
o el World Wide Web. VBScript tiene la eficacia de Visual Basic y permite que
los programadores aprovechen sus conocimientos de Visual Basic para crear
rápidamente soluciones para Internet o para el World Wide Web.

VBScript acepta un subconjunto de la sintaxis del lenguaje Visual Basic para
aplicaciones. Visual Basic Scripting Edition no incluye un entorno de desarrollo
como el de Visual Basic, ya que está diseñado para ser un motor ligero y para
compartirlo entre varias plataformas diferentes. Puede escribir código VBScript
con el Editor de código de Visual Basic, pero no puede ejecutar ni probar la
aplicación dentro del entorno de desarrollo de Visual Basic.

Como VBScript es un lenguaje de desarrollo multiplataforma, no incluye
algunos de los elementos del lenguaje de Visual Basic para aplicaciones. Entre
estos se encuentran las funciones de entrada y salida de archivos, las
constantes intrínsecas, los tipos de datos intrínsecos, etc. Cuando transporta
código desde Visual Basic a VBScript, es conveniente que lo repase para eliminar
los elementos no aceptados.

[Aplicaciones compiladas frente a interpretadas]

Aplicaciones compiladas
frente a interpretadas

De forma predeterminada, las aplicaciones creadas en Visual Basic se compilan
como ejecutables interpretados o en p-code. En tiempo de ejecución, las
instrucciones de los ejecutables se traducen o interpretan mediante una
biblioteca de vínculos dinámicos (DLL) de tiempo de ejecución. La Edición
Profesional y la Edición Empresarial de Visual Basic incluyen la opción de
compilar un archivo .exe en código nativo. En muchos casos, compilar a código
nativo puede aportar aumentos substanciales de velocidad sobre las versiones
interpretadas de la misma aplicación; sin embargo, no siempre ocurre así. Las
siguientes son algunas recomendaciones generales relacionadas con la compilación
a código nativo.

 
• El código que realiza muchas operaciones primitivas sobre variables con
    tipo que no son cadenas ofrece una mejor relación de código nativo generado en
    comparación con las operaciones de p-code. Por tanto, los cálculos financieros
    complejos o la generación de fractales se beneficiarán del código
    nativo.
• Los programas de cálculo intensivo o los programas que manejan muchos bits
    y bytes dentro de estructuras de datos locales ganarán bastante con el código
    nativo.
• En muchos programas, especialmente aquellos que hacen muchas llamadas a la
    API de Windows, llamadas a los métodos COM y manipulación de cadenas, el
    código nativo no será mucho más rápido que el p-code.
• Las aplicaciones que consisten principalmente de funciones de la
    biblioteca de ejecución de Visual Basic para aplicaciones no obtendrán una
    gran diferencia en el código nativo, ya que el código de la biblioteca de
    ejecución de Visual Basic para aplicaciones ya está muy optimizado.
• El código que consiste en muchas llamadas a subrutinas relativas a
    procedimientos en línea tampoco parecerá mucho más rápido con código nativo.
    Esto se debe a que el trabajo de establecer la pila, inicializar las variables
    y liberar todo al salir lleva tanto tiempo con el motor de p-code como con el
    código nativo.

Observe que las llamadas a los objetos, a los archivos DLL o a las funciones
de ejecución de Visual Basic para aplicaciones no aprovechan las ventajas del
código nativo. Esto se debe a que se pasa muy poco tiempo ejecutando código: la
mayor parte del tiempo (normalmente entre el 90% y el 95%) se pasa dentro de los
formularios, los objetos de datos, los archivos .dll de Windows o la ejecución
de Visual Basic para aplicaciones, que incluye el tratamiento de cadenas y
variables Variant incorporadas.

En las pruebas reales, las aplicaciones cliente pasan aproximadamente el 5%
del tiempo total de ejecución en el p-code. Por tanto, si el código nativo es
instantáneo, el uso del código nativo en estos programas proporcionará como
máximo una mejora del 5% en el rendimiento.

Lo que el código nativo ofrece a los programadores es la posibilidad de
escribir con Visual Basic partes del código o algoritmos de cálculo intensivo
que no eran posibles anteriormente por razones de rendimiento. Al permitir que
estos "retazos" se ejecuten con mucha más rapidez, también se puede aumentar el
tiempo de respuesta de ciertas partes de una aplicación, lo que mejora el
rendimiento perceptible de la aplicación en su conjunto.

[Optimizar los objetos]

Optimizar los objetos

Al usar más y más objetos en las aplicaciones de Visual Basic, la
optimización del uso de los objetos se hace cada vez más importante. Hay varias
técnicas clave para hacer un uso eficaz de los objetos:

 
• Usar enlaces en tiempo de diseño.
• Minimizar los puntos.
• Usar Set y With...End With.
• Minimizar las llamadas externas.

En Visual Basic, la referencia a un objeto de otra aplicación desde el
código (al obtener o establecer una de sus propiedades o al ejecutar uno
de sus métodos) constituye una llamada externa. Las llamadas externas son
costosas y debe evitarlas si quiere optimizar la aplicación.


Enlazar en tiempo de diseño frente a enlazar en tiempo de compilación

Visual Basic puede usar los objetos con más eficiencia si los puede enlazar
en tiempo de diseño. Un objeto puede enlazarse en tiempo de diseño si incluye
una referencia a la biblioteca de tipos que contiene el objeto y declara el tipo
del objeto:

Código [Seleccionar] Expandir

Dim X As New MiObjeto


O bien, su equivalente:

Código [Seleccionar] Expandir

Dim X As MiObjeto
Set X = New MiObjeto


El enlace en tiempo de diseño permite que Visual Basic realice la mayor parte
del trabajo de resolver la definición del objeto en tiempo de compilación en
lugar de hacerlo en tiempo de ejecución, que es cuando tiene impacto sobre el
rendimiento. Esto también permite que Visual Basic compruebe la sintaxis de las
propiedades y los métodos utilizados con el objeto y que le informe si hay
errores.

Si Visual Basic no puede enlazar en tiempo de diseño un objeto, tiene que
hacerlo en tiempo de compilación. Este enlace es costoso: en tiempo de
compilación no se dispone de la comprobación de errores y cada referencia en
tiempo de ejecución requiere al menos un 50% más de trabajo para Visual Basic.
Generalmente, debe enlazar los objetos en tiempo de diseño si es posible. Las
únicas veces que debe declarar una variable As Object es cuando no tiene
una biblioteca de tipos del objeto en cuestión o cuando necesita pasar cualquier
tipo de objeto como argumento de un procedimiento.


Minimizar los puntos

Cuando hace referencia a los objetos de otras aplicaciones desde Visual
Basic, utiliza la sintaxis "." para recorrer toda la jerarquía de
colecciones, objetos, propiedades y métodos de un objeto. Es frecuente encontrar
largas cadenas de recorrido. Por ejemplo:

Código [Seleccionar] Expandir

' Referencia a la celda A1 de Sheet1 del primer libro
' de trabajo de una hoja de cálculo de Microsoft Excel.
Application.Workbooks.Item(1).Worksheets.Item_
("Sheet1").Cells.Item(1,1)


Además de ser una cadena muy larga en su escritura, esta línea de código
es bastante difícil de leer y es muy poco eficiente.
Cuando llama a un objeto desde Visual Basic, cada "punto" requiere que Visual
Basic haga varias llamadas.
Para escribir aplicaciones más eficientes, minimice el uso de puntos para
hacer referencia a los objetos.
Normalmente puede minimizar los puntos si analiza los objetos y los métodos
disponibles. Por ejemplo, la línea de código anterior puede acortarse si elimina
el método Item (es el método predeterminado de las colecciones y no se
suele usar en el código) y si utiliza el método Range, que es más
eficaz:

Código [Seleccionar] Expandir

' Referencia a la celda A1 de Sheet1 del primer libro
' de trabajo de una hoja de cálculo de Microsoft Excel.
Application.Workbooks(1).Worksheets("Sheet1")_
.Range("A1")


Puede acortarla más aún si escribe el código para que haga referencia
a la hoja activa del libro de trabajo activo, en lugar de hacer referencia a una
hoja y a un libro de trabajo concretos:

Código [Seleccionar] Expandir

' Referencia a la celda A1 de la hoja activa del
' libro de trabajo activo.
Range("A1")


Por supuesto, en el ejemplo anterior se supone que puede hacer referencia a
la celda A1 de cualquier hoja que se encuentre activa.


Usar Set y With...End With

La instrucción Set también le permite acortar las cadenas de
exploración y le ofrece mayor control sobre el código. El siguiente
ejemplo utiliza instrucciones Dim y Set para crear variables que
hacen referencia a los objetos de uso más frecuente:

Código [Seleccionar] Expandir

Dim xlRange As Object
Set xlRange = Application.ActiveSheet.Cells(1,1)
xlRange.Font.Bold = True
xlRange.Width = 40


Visual Basic proporciona la estructura With...End With para establecer
un objeto implícito dentro del código:

Código [Seleccionar] Expandir

With Application.ActiveSheet.Cells(1,1)
   .Font.Bold = True
   .Width = 40
End With




Minimizar las llamadas externas

Si va a usar un componente ActiveX externo, no puede evitar totalmente las
llamadas externas. Sin embargo, hay varias maneras de minimizar el número de
llamadas externas necesarias. Si es posible, no haga referencia a objetos dentro
de un bucle For...Next. Pase los valores a variables y utilice las
variables dentro de los bucles. Si tiene que llamar a muchos métodos de un
objeto, puede aumentar notablemente el rendimiento de la aplicación mediante el
paso de código al componente. Por ejemplo, si el componente es Word o
Microsoft Excel, puede colocar una macro con el bucle en una plantilla de Word o
un procedimiento con el bucle en un módulo de Microsoft Excel. Después llame a
la macro o al procedimiento desde Visual Basic, que es una única llamada que
inicia la operación en bucle dentro del componente.

Cuando escribe componentes, puede diseñar objetos eficientes de los
componentes si reduce las llamadas externas requeridas para realizar una
operación. Por ejemplo, cuando tiene varias propiedades interrelacionadas,
escriba un método con varios argumentos, uno para cada propiedad. La llamada al
método requiere una única llamada externa independientemente de los argumentos
que tenga, mientras que establecer cada propiedad requiere una llamada externa
distinta. De igual forma, si anticipa que el componente que actúa como cliente
va a llamar al componente dentro de un bucle (por ejemplo, para sumar o
promediar los valores de una propiedad de lista), puede aumentar el rendimiento
mediante métodos que hagan el bucle dentro del objeto y que devuelvan el
resultado.

Para obtener más información   La creación de
componentes se describe en profundidad en la Guía de herramientas
componentes incluida en la Edición Profesional y la Edición Empresarial de
Visual Basic.

[Aplicaciones segmentadas]

Aplicaciones segmentadas

Visual Basic le permite plantear la arquitectura de su aplicación de nuevas
maneras. En lugar de un único ejecutable monolítico, puede escribir una
aplicación que consista en un núcleo ejecutable inicial soportado por varios
componentes ActiveX. Esta técnica ofrece importantes ventajas de optimización:

 
• Los componentes se cargan bajo demanda y se pueden descargar cuando no se
    necesitan.
• Los componentes externos pueden ser ejecutables de 32 bits en
    Windows 95 o en Windows NT, incluso aunque otras partes de la aplicación
    sean componentes de 16 bits.
• Los componentes remotos pueden usar los recursos de otras máquinas de la
    red.

Además, los componentes se pueden depurar de forma independiente y se pueden
volver a usar en otras aplicaciones. Puede que esto no aumente la velocidad de
la aplicación, pero puede aumentar la velocidad al crear la siguiente.

Para determinar cómo optimizar mejor la aplicación mediante su segmentación,
debe evaluar los tipos de componentes que puede crear y cómo encajan con la
aplicación. Hay tres tipos de componentes que puede crear con la Edición
Profesional o la Edición Empresarial de Visual Basic:

 
• Externos
• Internos
• Remotos

Estos tres tipos no son exclusivos: puede usar los tres en una misma
aplicación. Pero desde el punto de vista de la optimización de la aplicación,
cada uno de ellos tiene características muy diferentes.


Componentes externos

Los componentes externos son programas ejecutables que ofrecen sus servicios
a otros programas. Como todos los ejecutables, se inician y se ejecutan con sus
propias pilas dentro de sus propios espacios de proceso; de esta forma, cuando
una aplicación que actúa como cliente utiliza uno de los objetos proporcionados
por un componente, la operación pasa del espacio de proceso del cliente al del
componente, de ahí su nombre. Los componentes externos ofrecen características
muy valiosas si se comparan con los otros tipos:

 
• Operación asíncrona ("subprocesos").
• Los errores no interceptados en el componente no provocan la caída de la
    aplicación cliente.
• Interoperabilidad entre aplicaciones de 16 bits y 32 bits.

De estas características, la primera y la última tienen especial interés
desde el punto de vista de la optimización.

Puesto que un componente externo es un programa independiente, puede operar
de forma asíncrona con el componente que actúa como cliente. Tiene un
"subproceso" independiente que se ejecuta simultáneamente con el programa
cliente (técnicamente hablando, no se trata de un subproceso, sino de un proceso
independiente; sin embargo, conceptualmente son equivalentes). Los dos programas
pueden comunicarse y compartir objetos, pero se ejecutan de forma independiente.
Esto es especialmente útil cuando la aplicación necesita realizar alguna
operación de larga duración. El cliente puede llamar al componente para que
realice la operación y después continuar atendiendo al usuario.

Incluso si la aplicación va a ejecutarse en un sistema de 32 bits, es posible
que no pueda pasarla a 32 bits de forma inmediata si utiliza aplicaciones o
componentes heredados de 16 bits. Sin embargo, si segmenta la aplicación
mediante componentes externos, puede mezclar y asociar componentes de 16 bits y
de 32 bits. Esto le permite aprovechar cada vez más las características y el
rendimiento de 32 bits, al tiempo que conserva los componentes de 16 bits que ya
tiene.

Pese a toda su eficacia, los componentes externos tienen un notable
inconveniente: su poco rendimiento. Se manifiesta de dos maneras:

 
• Velocidad inicial
• Carga de trabajo de la llamada externa

Un componente externo es un ejecutable creado con Visual Basic, de modo que
los problemas relacionados con su inicio son los mismos que se presentan con
cualquier aplicación. Lo bueno es que, si va a llamar a un componente externo
escrito en Visual Basic desde otro programa de Visual Basic, casi todos los
archivos DLL ya estarán cargados. Esto reduce en gran medida el tiempo de inicio
del componente. Muchos componentes son más pequeños que la media de las
aplicaciones de Visual Basic y tienen pocos o ningún formulario que cargar, lo
que de nuevo mejora su tiempo de carga. No obstante, los componentes externos
siempre se cargarán con mayor lentitud que los componentes internos.

Una vez en ejecución, el componente externo tiene las limitaciones de su
propia naturaleza: cada interacción con el componente es una llamada externa.
Los pasos entre procesos consumen muchos ciclos de CPU. De este modo, las
referencias a los objetos del componente externo son mucho más costosas que sus
equivalentes a los objetos de la misma aplicación cliente o de un componente
interno. Reducir el número de llamadas externas en el código puede
reducir el impacto de la carga de trabajo de estas llamadas.


Componentes internos

Los componentes internos ofrecen sus servicios a otros programas que están
dentro de su mismo espacio de proceso. Comparados con los componentes externos,
los componentes internos ofrecen dos ventajas:

 
• Menor tiempo de carga
• No hacen llamadas externas

Con los componentes internos no necesita crear un nuevo proceso ni cargar los
archivos DLL en tiempo de ejecución. Por esto, los componentes internos son
considerablemente más rápidos en su carga si se comparan con los componentes
externos equivalentes.

Al ser internos, no se producen llamadas externas cuando se hace referencia a
los métodos o las propiedades de un objeto proporcionado por el componente. Los
objetos del componente operan con la misma eficacia que los objetos de la
aplicación cliente propiamente dicha.


Componentes remotos

La Edición Empresarial de Visual Basic le permite crear componentes remotos
que se ejecutan en una máquina diferente en cualquier parte de la red. Aunque
los retrasos debidos a la red supondrán inevitablemente una disminución del
rendimiento de la aplicación, pueden compensar por el uso de los recursos de las
CPU adicionales. Esto es especialmente cierto cuando trabaja con un componente
remoto que opera sobre datos locales de la máquina que contiene el componente.
Puesto que los datos tendrán que transferirse a través de la red de todas
maneras, un componente que opera sobre ellos de forma local y sólo devuelve a
través de la red los resultados puede ser realmente más eficaz.

Por ejemplo, puede crear un objeto en un componente que busca los archivos
que cumplen unos criterios especificados dentro del disco duro local. Si hace
que el componente sea remoto y coloca una copia del mismo en todas las máquinas
de la red, puede escribir un programa de búsqueda de archivos distribuidos que
explore todos los componentes de la red en paralelo mediante los recursos de
todas las CPU.

[Recortar los gráficos]

Recortar los gráficos

Los gráficos (las imágenes y los métodos gráficos) pueden consumir una gran
cantidad de memoria. En cierto modo es inevitable: los gráficos contienen mucha
información y suelen ser grandes. Pero en muchos casos puede reducir el impacto
de los gráficos sobre el tamaño de la aplicación si emplea alguna de las
técnicas siguientes:

 
• Usar el control Image para presentar mapas de bits.
• Cargar los mapas de bits desde archivos cuando sean necesarios y compartir
    imágenes.
• Usar el método PaintPicture.
• Liberar la memoria utilizada por los gráficos.
• Usar mapas de bits en formato .rle o metarchivos.

Usar el control Image para presentar mapas de bits

Los controles Picture de muchas aplicaciones de Visual Basic sólo
existen para hacer clic en ellos o para arrastrarlos y colocarlos. Si esto es
todo lo que va a hacer con un control Picture, está malgastando muchos
recursos de Windows. Para estos mismos propósitos, los controles Image
son mejores que los controles Picture. Cada control Picture es una
ventana real y utiliza bastantes recursos del sistema. El control Image
es un control "ligero", no una ventana, y no utiliza tantos recursos. De hecho,
normalmente puede usar entre cinco y diez controles Image por cada
control Picture. Además, los controles Image se dibujan más rápido
que los controles Picture. Utilice los controles Picture
únicamente cuando necesite alguna de las características que sólo estos
proporcionan, como el intercambio dinámico de datos (DDE), los métodos gráficos
o la posibilidad de contener otros controles.


Cargar los mapas de bits desde archivos cuando sean necesarios y compartir
imágenes

Cuando establece una propiedad Picture en tiempo de diseño, agrega la
imagen al formulario e incrementa la memoria consumida por el formulario en
tiempo de ejecución. Puede reducir el consumo de memoria si almacena las
imágenes en un archivo de recursos y utiliza la función LoadResPicture
para cargarlos en tiempo de ejecución. Si nunca utiliza todas las imágenes
asociadas con un formulario al mismo tiempo, esta técnica ahorra memoria en
comparación con la de almacenar todas las imágenes en los controles del
formulario. Puede acelerar la velocidad de carga del formulario porque no todas
las imágenes tienen que cargarse antes de presentar el formulario.
Puede compartir la misma imagen entre varios controles Picture,
controles Image y formularios. Si utiliza código de este tipo,
sólo mantiene una copia de la imagen:

Código [Seleccionar] Expandir

Picture = LoadPicture("C:\Windows\Chess.bmp")
Image1.Picture = Picture   ' Utiliza la misma imagen.
Picture1.Picture = Picture   ' Utiliza la misma imagen.


Contraste lo anterior con el siguiente código, que hace cargar tres
mapas de bits y, por tanto, necesita más memoria y más tiempo:

Código [Seleccionar] Expandir

Picture = LoadPicture("C:\Windows\Chess.bmp")
Image1.Picture = LoadPicture("C:\Windows\Chess.bmp")
Picture1.Picture = LoadPicture("C:\Windows\Chess.bmp")


De forma similar, si carga la misma imagen en varios formularios o controles
en tiempo de diseño, se guarda una copia de dicha imagen con cada formulario o
con cada control. En vez de esto, puede colocar la imagen en un formulario y
después compartirla con los demás formularios y controles de la forma descrita
anteriormente. Esto hace que la aplicación sea más pequeña (porque no tiene
copias redundantes de la misma imagen) y más rápida (porque no hay que cargar la
imagen varias veces desde el disco).


Usar el método PaintPicture

En lugar de colocar mapas de bits en los controles, puede usar el método
PaintPicture para presentar mapas de bits en cualquier parte de los
formularios. Esto es especialmente útil cuando quiere dibujar varias veces en
mosaico un mismo mapa de bits en un formulario: sólo necesita cargar el mapa de
bits una vez y usar PaintPicture para dibujarlo varias veces.


Liberar la memoria utilizada por los gráficos

Cuando ya no va a usar una imagen de la propiedad Picture de un
formulario, de un cuadro de imagen o de un control Image, establezca la
propiedad Picture a Nothing para dejarla vacía:

Código [Seleccionar] Expandir

Set Picture1.Picture = Nothing


Si utiliza la propiedad Image de un cuadro de imagen o de un
formulario, Visual Basic crea un mapa de bits AutoRedraw (incluso si la
propiedad AutoRedraw de dicho formulario o cuadro de imagen es
False). Cuando ha terminado de usar la propiedad Image, puede
liberar la memoria utilizada por ese mapa de bits si utiliza el método
Cls antes de establecer AutoRedraw a False. Por ejemplo, el
código siguiente libera la memoria utilizada por la propiedad
Image en un control llamado midib:

Código [Seleccionar] Expandir

midib.AutoRedraw = True         ' Activa el mapa de bits
                              ' AutoRedraw.
midib.Cls                     ' Lo borra.
midib.AutoRedraw = False      ' Desactiva el
                              ' mapa de bits.




Usar mapas de bits en formato .rle o metarchivos

Aunque el formato de imagen predeterminado es el mapa de bits (.bmp), Visual
Basic también puede usar otros formatos de archivos gráficos. Varios programas
de dibujo y de gráficos le permiten guardar los mapas de bits en un formato de
mapa de bits comprimido estándar llamado Run Length Encoded (.rle). Los mapas de
bits .rle pueden ser varias veces más pequeños que sus equivalentes no
comprimidos, especialmente los mapas de bits que contienen grandes partes de
colores sólidos. Además, no se aprecia que sean más lentos de cargar o
presentar. El uso de metarchivos (.wmf) puede ahorrar aún más espacio, hasta 10
veces o más en algunos casos. Intente usar los metarchivos en su tamaño normal:
es más lento dibujarlos si es necesario ampliarlos o reducirlos.
También puede usar los formatos .gif y .jpg. Estos formatos suelen ser mucho
más pequeños; sin embargo, hay algunos inconvenientes en cuanto a la calidad de
la imagen y la velocidad de carga.

[Reducir el tamaño del código]

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 cargados


Cada 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:

Código [Seleccionar] Expandir

Set Form = Nothing



Reducir el número de controles

Cuando 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 texto

Los 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:

Código [Seleccionar] Expandir

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 necesarios

Los 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ódulos

Visual 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 Variant

El 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 memoria

Piense 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:

Código [Seleccionar] Expandir

Erase MiMatriz


Mientras Erase elimina completamente la matriz, ReDim Preserve
reduce su tamaño sin perder el contenido:

Código [Seleccionar] Expandir

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
objeto

El 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:

Código [Seleccionar] Expandir

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:

Código [Seleccionar] Expandir

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 utilizan

Al 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".

[Optimizar el Tamaño]

Optimizar el Tamaño

En el pasado, la memoria disponible y los recursos del sistema solían ser factores restrictivos en el diseño de una aplicación. En los sistema operativos de 32 bits, como Windows 95 y Windows NT, estos factores raramente suponen una preocupación para la mayoría de los programadores de Visual Basic. Sin embargo, hay varios escenarios en los que sigue siendo importante minimizar el tamaño de una aplicación.

El tamaño es extremadamente importante en las aplicaciones que se cargan desde Internet o se transfieren como adjuntos de correo electrónico. Para los poco afortunados que no tienen conexiones de datos de alta velocidad, la transferencia de un archivo de 1 megabyte podría durar una hora o más. Además del archivo .exe, muchas aplicaciones requieren archivos .dll y .ocx adicionales, lo que incrementa el tamaño (y el tiempo) de la transferencia. En estos escenarios, le interesa optimizar el tamaño en disco de las aplicaciones.

Incluso si los usuarios no van a transferir su aplicación, siempre conviene hacer que una aplicación sea lo más compacta posible. Las aplicaciones pequeñas se cargan con mayor rapidez y como consumen menos memoria, puede ejecutar otras aplicaciones al mismo tiempo. A menudo puede mejorar el rendimiento si optimiza el tamaño de la aplicación en la memoria.

[Medir el rendimiento]

Medir el rendimiento

Determinar qué algoritmo es el mejor para una situación dada no es siempre
obvio. Algunas veces necesitará comprobar sus hipótesis; esto puede hacerse
fácilmente creando una aplicación sencilla para medir el rendimiento, como la
mostrada a continuación. La aplicación de ejemplo Optimize.vbp también contiene
ejemplos de distintos escenarios de prueba.

Para crear una aplicación de prueba de rendimiento

 
• Abra un nuevo proyecto .exe.
• Cree un formulario con dos botones de comando: Command1 y Command2.
En el evento Command1_Click, agregue el código siguiente:

Código [Seleccionar] Expandir

Private Sub Command1_Click()
Dim dblStart As Double
Dim dblEnd As Double
Dim i as Long
dblStart = Timer        ' Hora de inicio.
For i = 0 To 9999
»Rutina para probar«    ' Escriba su rutina aquí.
Next
dblEnd = Timer            ' Hora de terminación.
Debug.Print dblEnd - dblStart    ' Presenta el
' tiempo
' transcurrido.
End Sub


  [li]Agregue el mismo código al evento Command2_Click, pero utilice la segunda
  versión de su rutina en el bucle.[/li]
  [li]Ejecute la aplicación y siga los resultados en la ventana Inmediato.
[/li][/list]

Este ejemplo utiliza la propiedad predeterminada de la clase Timer de
Visual Basic para medir el tiempo de ejecución de la rutina dentro del bucle. Al
colocar el código dentro del bucle de cada botón de comando, puede comparar
rápidamente el rendimiento de los dos algoritmos. El código puede estar dentro
del bucle o puede ser una llamada a otros procedimientos.

Puede que tenga que experimentar con valores diferentes en los límites
superiores del contador del bucle, especialmente en las rutinas rápidas.
Asegúrese de ejecutar cada versión varias veces para obtener un promedio; los
resultados pueden variar entre una ejecución y otra.

También puede optimizar su aplicación si incrementa la velocidad de acceso a
los datos.