Mensajes

[Optimizar la velocidad percibida]

Optimizar la velocidad
percibida

Suele ocurrir que la velocidad subjetiva de su aplicación tiene poco que ver
con la rapidez de ejecución del código. Para el usuario, una aplicación que se
inicie con rapidez, se dibuje con rapidez y proporcione mensajes de forma
continua da la sensación de ser más "garbosa" que una aplicación que se queda
"parada" mientras hace su trabajo. Puede usar una gama variada de técnicas para
aportar dicho "garbo" a su aplicación:

 
• Mantener los formularios ocultos pero cargados.
• Cargar los datos previamente.
• Usar cronómetros para trabajar en segundo plano.
• Usar indicadores de progreso.
• Acelerar el inicio de la aplicación.

Mantener los formularios ocultos pero cargados

Ocultar los formularios en lugar de descargarlos es un truco que viene de las
primeras épocas de Visual Basic 1.0, pero sigue siendo efectivo. El
inconveniente obvio de esta técnica es la cantidad de memoria que consumen los
formularios cargados, pero puede desestimarlo si puede permitirse el gasto en
memoria, ya que hacer que los formularios aparezcan con rapidez es de la máxima
importancia.


Cargar los datos previamente

También puede mejorar la velocidad aparente de la aplicación si carga los
datos previamente. Por ejemplo, si necesita ir al disco a cargar el primero de
varios archivos, ¿por qué no cargar todos los que pueda? A menos que los
archivos sean extremadamente pequeños, el usuario advertirá el retraso de todos
modos. Probablemente, el incremento del tiempo empleado en la carga de los
archivos adicionales pasará inadvertido y, además, no tendrá que hacer esperar
al usuario otra vez.


Usar cronómetros para trabajar en segundo plano

En algunas aplicaciones se puede realizar una cantidad considerable de
trabajo mientras se espera al usuario. La mejor manera de hacerlo es mediante un
control Timer. Utilice variables estáticas (o de nivel de módulo) para
hacer un seguimiento del progreso y ejecute una pequeña parte del trabajo cada
vez que salte el cronómetro. Si hace que la cantidad de trabajo realizado entre
cada evento del cronómetro sea muy pequeña, los usuarios no verán efecto alguno
sobre la respuesta de la aplicación y podrá cargar datos o efectuar otras tareas
que aceleren aún más la velocidad de su aplicación.

Para obtener más información   Para aprender más
acerca del control temporizador, vea "Usar el control Timer" en "Usar los
controles estándar de Visual Basic". Para obtener la descripción del proceso en
segundo plano, vea "Interrumpir el procesamiento en segundo plano" en "Responder
a los eventos del mouse y del teclado".


Usar indicadores de progreso

Cuando no pueda evitar una larga espera en el programa, tiene que ofrecer al
usuario alguna indicación de que la aplicación no se ha quedado bloqueada.
Windows 95 utiliza una barra de progreso estándar para indicar esto a los
usuarios. Puede usar el control ProgressBar de los Controles comunes de
Microsoft Windows incluidos en la Edición Profesional y en la Edición
Empresarial de Visual Basic. Utilice DoEvents en los puntos estratégicos,
especialmente cada vez que actualice el valor del control ProgressBar,
para permitir que la aplicación dibuje mientras el usuario hace otras cosas.
Como mínimo admisible, debe presentar el cursor para indicar la espera
mediante el valor vbHourglass (11) de la propiedad MousePointer
del formulario (11).


Acelerar el inicio de la aplicación

La velocidad aparente tiene la máxima importancia cuando se inicia su
aplicación. La primera impresión de los usuarios sobre la velocidad de una
aplicación se mide por la rapidez con la que pueden hacer algo después de
seleccionar el nombre de la aplicación en el menú Inicio. Con las
diversas DLL de tiempo de ejecución que tienen que cargarse para Visual Basic
para aplicaciones, los controles ActiveX y todo lo demás, es inevitable un
pequeño retraso en cualquier aplicación. Sin embargo, puede hacer varias cosas
para dar respuesta al usuario de la forma más rápida posible:

 
• Usar Show en el evento Form_Load.
• Simplificar el formulario inicial.
• No cargar los módulos que no necesite.
• Ejecutar una pequeña aplicación de Visual Basic al iniciar para cargar
    previamente los archivos DLL de tiempo de ejecución.

Usar Show en el evento Form_Load

Cuando un formulario se carga por primera vez, todo el código del evento
Form_Load se ejecuta antes de presentar el formulario. Puede alterar este
comportamiento si utiliza el método Show en el evento Form_Load para
ofrecer al usuario algo que mirar mientras se ejecuta el resto del código del
evento. Siga al método Show con DoEvents para asegurar que se
dibuja el formulario:

Código [Seleccionar] Expandir

Sub Form_Load()
   Me.Show         ' Presenta el formulario inicial.
   DoEvents         ' Asegura que se dibuja el
                  ' formulario inicial.
   Load MainForm   ' Carga el formulario principal.
   Unload Me      ' Descarga el formulario inicial.
   MainForm.Show   ' Presenta el formulario principal.
End Sub


Simplificar el formulario inicial

Cuanto más complicado es un formulario, más tiempo necesita para cargarse.
Simplifique su formulario inicial. La mayor parte de las aplicaciones para
Microsoft Windows presentan al iniciarse una pantalla de copyright sencilla
(también conocida como pantalla de bienvenida); su aplicación puede hacer lo
mismo. Cuantos menos controles y cuanto menos código contiene el formulario
inicial, más rápido se cargará y aparecerá. Incluso aunque cargue otro más
complicado inmediatamente, el usuario sabrá que la aplicación se ha
iniciado.

En las aplicaciones grandes puede que le interese cargar previamente en el
inicio los formularios utilizados con mayor frecuencia para mostrarlos
instantáneamente cuando sea necesario. Una manera satisfactoria de hacer esto es
presentar una barra de progreso en el formulario inicial y actualizarla al
cargar cada uno de los demás formularios. Llame a DoEvents después de
cargar cada formulario para volver a dibujar el formulario inicial. En cuanto se
han cargado todos los formularios importantes, el formulario inicial puede
presentar el primero y descargarse a sí mismo. Por supuesto, cada formulario que
cargue ejecutará el código de su evento Form_Load, de modo que preste atención
para que esto no provoque problemas o retrasos excesivos.


No cargar los módulos que no necesite

Visual Basic carga los módulos de código cuando se solicita, en lugar de
todos a la vez al iniciar. Esto significa que si nunca llama a un procedimiento
de un módulo, ese módulo no se cargará nunca. Por el contrario, si el formulario
inicial llama a procedimientos de varios módulos, todos estos módulos se
cargarán mientras se inicia la aplicación, lo que la retrasa. Por tanto, debe
evitar llamar a procedimientos de otros módulos desde el formulario inicial.


Ejecutar una pequeña aplicación de Visual Basic al iniciar para cargar los
archivos DLL de tiempo de ejecución

Gran parte del tiempo que se requiere para iniciar una aplicación de Visual
Basic se emplea en cargar los archivos DLL de tiempo de ejecución para Visual
Basic, ActiveX y los controles ActiveX. Desde luego, si estos ya estuvieran
cargados, no se emplearía tanto tiempo. De esta forma los usuarios verán que la
aplicación se inicia con más rapidez si ya se está ejecutando otra aplicación
que utiliza alguna o todas estas DLL.

Una forma de aumentar el rendimiento inicial de las aplicaciones de forma
significativa es proporcionar otra pequeña aplicación que se ejecute siempre.
Por ejemplo, puede escribir una pequeña aplicación para presentar un calendario
e instalarla en el grupo Inicio de Windows. De este modo, se cargará
automáticamente al iniciar el sistema y, además de ser útil por sí misma,
asegura que se carguen las diversas DLL de tiempo ejecución de Visual Basic.
Finalmente, con la Edición Profesional y la Edición Empresarial de Visual
Basic puede dividir su aplicación en un esqueleto de aplicación principal y
varios componentes ejecutables o varias DLL. Una aplicación principal pequeña se
cargará con más rapidez y después podrá cargar las otras partes cuando las
necesite.

[Optimizar la velocidad de presentación]

Optimizar la velocidad de
presentación

Debido a la naturaleza gráfica de Microsoft Windows, la velocidad de los
gráficos y de otras operaciones de presentación es crucial para la
velocidad percibida de una aplicación. Cuanto más rápido se
presenten los formularios, más rápida le parecerá su aplicación al usuario. Hay
varias técnicas que puede usar para aumentar la velocidad aparente de su
aplicación, entre las que se incluyen:

 
• Establecer la propiedad ClipControls de los contenedores a
    False.
• Usar AutoRedraw de forma apropiada.
• Usar controles de imagen en vez de controles de cuadro de imagen.
• Ocultar los controles al establecer propiedades para evitar que se vuelvan
    a dibujar.
• Usar Line en lugar de PSet.

Establecer la propiedad ClipControls de los contenedores a False

A menos que utilice métodos gráficos (Line, PSet, Circle
y Print), debe establecer ClipControls a False en el
formulario y en todos los controles de marco y de cuadro de imagen (puede haber
resultados impredecibles si el código incluye métodos gráficos que dibujan
detrás de otros controles). Cuando ClipControls es False, Visual
Basic no dibuja el fondo de los controles antes de volver a dibujar los
controles propiamente dichos. En los formularios que contienen muchos controles,
el resultado sobre la velocidad es significativo.


Usar AutoRedraw de forma apropiada

Cuando se establece AutoRedraw a True en un formulario o en un
control, Visual Basic mantiene un mapa de bits para volver a dibujar el
formulario o el control. Aunque esto mejora la velocidad de los dibujos simples
(por ejemplo, cuando el formulario o el control queda al descubierto después de
que la ventana que lo cubre se cierra), hace más lentos los métodos gráficos.
Visual Basic tiene que ejecutar los métodos gráficos sobre el mapa de bits de
AutoRedraw y después copiar todo el mapa de bits a la pantalla. Este
proceso también consume una cantidad de memoria considerable.

Si la aplicación genera gráficos complejos pero no los modifica con
frecuencia, es correcto establecer AutoRedraw a True. Pero si la
aplicación dibuja gráficos que cambian con frecuencia, obtendrá un mejor
rendimiento si establece AutoRedraw a False y realiza los métodos
gráficos del formulario o del control dentro del evento Paint.
Para obtener más información   Vea "Capas de
gráficos con AutoRedraw y ClipControls" en "Trabajar con texto y gráficos".


Usar controles de imagen en vez de controles de cuadro de imagen

Esta optimización aumenta la velocidad y minimiza el tamaño de la aplicación;
utilícela siempre que sea posible. Cuando simplemente va a presentar imágenes y
a reaccionar a eventos de clic y acciones del mouse sobre ellos, utilice
controles de imagen en vez de cuadros de imagen. No utilice un cuadro de imagen
a menos que necesite las capacidades que sólo él proporciona, como los métodos
gráficos, la posibilidad de contener otros controles o el intercambio dinámico
de datos (DDE).


Ocultar los controles al establecer propiedades para evitar que se vuelvan a
dibujar

Es costoso volver a trazar dibujos en la pantalla. Cuantos menos dibujos
tenga que realizar Visual Basic, más rápida parecerá la aplicación. Una manera
de reducir el número de dibujos es hacer invisibles los controles mientras se
manipulan. Por ejemplo, suponga que quiere cambiar el tamaño de varios cuadros
de lista en el evento Resize del formulario:

Código [Seleccionar] Expandir

Sub Form_Resize ()
Dim i As Integer, sHeight As Integer
   sHeight = ScaleHeight / 4
   For i = 0 To 3
      lstDisplay(i).Move 0, i * sHeight, _
      ScaleWidth, sHeight
   Next
End Sub


Este código crea cuatro dibujos separados, uno por cada cuadro de lista.
Puede reducir el número de dibujos si coloca todos los cuadros de lista dentro
de un cuadro de imagen y oculta el cuadro de imagen antes de mover y ajustar el
tamaño de los cuadros de lista. Después, cuando vuelve a hacer visible el cuadro
de imagen, todos los cuadros de lista se dibujan en una única pasada:

Código [Seleccionar] Expandir

Sub Form_Resize ()
Dim i As Integer, sHeight As Integer
   picContainer.Visible = False
   picContainer.Move 0, 0, ScaleWidth, ScaleHeight
   sHeight = ScaleHeight / 4
   For i = 0 To 3
      lstDisplay(i).Move 0, i * sHeight, _
      ScaleWidth, sHeight
   Next
   picContainer.Visible = True
End Sub


Observe que en este ejemplo se utiliza el método Move en lugar de
establecer las propiedades Top y Left. El método Move
establece las dos propiedades en una única operación, lo que ahorra dibujos
adicionales.

Usar Line en lugar de PSet

El método Line es más rápido que una serie de métodos PSet.
Evite el uso del método PSet y consiga el mismo resultado con un único
método Line. Los controles Shape y Line son adecuados para
los elementos gráficos que cambian raramente; los gráficos complejos o los
gráficos que cambian con rapidez generalmente se controlan mejor con métodos
gráficos.

[Optimizar el código]

Optimizar el código

A menos que desarrolle tareas como la generación de fractales, sus
aplicaciones raramente se verán limitadas por la velocidad de ejecución del
código. Normalmente son otros factores, como la velocidad de vídeo, los retrasos
de la red o la actividad del disco, los que limitan las aplicaciones. Por
ejemplo, cuando un formulario tarda en cargarse, puede deberse al número de
controles y gráficos del formulario más que a la lentitud del código del evento
Form_Load. Sin embargo, puede encontrar puntos del programa en los que la
velocidad del código es el factor principal, especialmente en las rutinas a las
que se llama con mucha frecuencia. Cuando éste sea el caso, puede usar varias
técnicas para incrementar la velocidad real de las aplicaciones:

 
• Evitar el uso de variables Variant.
• Usar variables Long Integer y aritmética de números
  enteros.
• Pasar a variables las propiedades utilizadas con mayor frecuencia.
• Usar variables de nivel de módulo en lugar de variables estáticas.
• Reemplazar las llamadas a procedimientos por código en línea.
• Usar constantes siempre que sea posible.
• Pasar argumentos con ByVal en lugar de ByRef.
• Usar argumentos opcionales con tipo.
• Usar colecciones.

Incluso si no va a optimizar la velocidad del código, conviene tener
presentes estas técnicas y los principios en los que se basan. Si adquiere el
hábito de elegir algoritmos más eficientes al escribir código, obtendrá una
ventaja adicional a la velocidad de la aplicación.


Evitar el uso de variables Variant

El tipo de datos predeterminado de Visual Basic es Variant. Es cómodo
para los programadores principiantes y en aplicaciones en las que la velocidad
de procesamiento no es importante. Sin embargo, si piensa optimizar la velocidad
real de su aplicación, debe evitar el uso de variables Variant. Como
Visual Basic convierte las variables Variant al tipo de datos apropiado
en tiempo de ejecución, las operaciones con otros tipos de datos simples
eliminan este paso adicional y son más rápidas que sus equivalentes
Variant.

Un buen sistema para no usar variables Variant es usar la instrucción
Option Explicit, que le obliga a declarar todas las variables. Para usar
Option Explicit, active la casilla de verificación Requerir
declaración de variables en la ficha Editor del cuadro de diálogo
Opciones, disponible en el menú Herramientas.

Tenga cuidado cuando declara múltiples variables: si no utiliza la cláusula
As tipo, se considerarán variables Variant. Por ejemplo, en la
siguiente declaración, X e Y son Variant:

Código [Seleccionar] Expandir

Dim X, Y, Z As Long


Escritas de esta manera, las tres variables son de tipo Long:

Código [Seleccionar] Expandir

Dim X As Long, Y As Long, Z As Long


Para obtener más información   Para aprender más
acerca de los tipos de datos de Visual Basic, vea "Tipos de datos" en
"Fundamentos de programación".

Uso de variables Long Integer y aritmética de números enteros

En las operaciones aritméticas, evite las variables Currency,
Single y Double. Utilice variables Long Integer siempre que
pueda, especialmente dentro de los bucles. Long Integer es el tipo de
datos nativo de las CPU de 32 bits, de forma que las operaciones efectuadas
sobre ellos son muy rápidas; si no puede usar la variable Long, la opción
más parecida son los tipos de datos Integer o Byte. En muchos
casos, puede usar el tipo Long Integer cuando se requiere un valor con
punto flotante. Por ejemplo, si establece la propiedad ScaleMode de todos
los formularios y controles de imágenes a twips o píxeles, puede usar el tipo
Long Integer en todos los valores de tamaño y posición de los controles y
los métodos gráficos.

Cuando realice divisiones, utilice el operador de división de enteros (\) si
no necesita un resultado decimal. La aritmética de números enteros siempre es
más rápida que la aritmética de punto flotante, ya que no hay que trasladar la
operación a un coprocesador matemático. Si necesita calcular valores decimales,
el tipo de datos Double es más rápido que el tipo de datos
Currency.

En la tabla siguiente los tipos de datos numéricos están clasificados según
su velocidad.


 
 
   
   
   
   
   
   
   

Tipo de datos numérico	Velocidad
Long	Máxima
Integer
Byte
Single
Double
Currency	Mínima

Almacenamiento en caché de las propiedades utilizadas con mayor frecuencia
en variables

Los valores de las variables se obtienen y se establecen con más rapidez que
los de las propiedades. Si va a leer frecuentemente el valor de una propiedad
(como en un bucle), su código se ejecutará más deprisa si asigna la propiedad a
una variable externa al bucle y después utiliza la variable en lugar de la
propiedad. Las variables suelen ser entre 10 y 20 veces más rápidas que las
propiedades del mismo tipo.

No lea nunca el valor de una propiedad más de una vez dentro de un
procedimiento, a menos que sepa que el valor ha cambiado. En su lugar, asigne el
valor de la propiedad a una variable y utilice la variable en el resto del
código. Por ejemplo, este código es muy lento:

Código [Seleccionar] Expandir

For i = 0 To 10
   picIcon(i).Left = picPallete.Left
Next I


Escrito de esta manera, es mucho más rápido:

Código [Seleccionar] Expandir

picLeft = picPallete.Left
For i = 0 To 10
      picIcon(i).Left = picLeft
Next I


De igual manera, este código . . .

Código [Seleccionar] Expandir

Do Until EOF(F)
   Line Input #F, nextLine
   Text1.Text = Text1.Text + nextLine
Loop


. . . es mucho más lento que éste:

Código [Seleccionar] Expandir

Do Until EOF(F)
   Line Input #F, nextLine
   bufferVar = bufferVar & nextLine & vbCrLf
Loop
Text1.Text = bufferVar


Sin embargo, este código hace el mismo trabajo y es aún más rápido:

Código [Seleccionar] Expandir

   Text1.Text = Input(F, EOF(F))


Como puede ver, hay varios métodos para conseguir el mismo objetivo; el mejor
algoritmo también es la mejor optimización.

La misma técnica puede aplicarse a los valores devueltos por las funciones.
Almacenar estos valores en memoria caché evita la repetición de las llamadas a
la biblioteca de vínculos dinámicos (DLL) de tiempo de ejecución,
Msvbvm60.dll.


Usar variables de nivel de módulo en lugar de variables estáticas
Aunque las variables declaradas con el modificador Static son útiles para
almacenar un valor a través de ejecuciones múltiples de un procedimiento, son
más lentas que las variables locales. Si almacena el mismo valor en una variable
de nivel de módulo, su procedimiento se ejecutará más rápidamente. Observe sin
embargo que deberá asegurarse de que un procedimiento tan sólo tiene la
posibilidad de modificar la variable a nivel de módulo. La contrapartida aquí es
que su código será menos legible y más difícil de mantener.


Reemplazar llamadas a procedimientos por código en línea

Aunque el uso de procedimientos hace que el código sea más modular, las
llamadas a los procedimientos siempre conllevan algo de proceso y de tiempo
adicionales. Si tiene un bucle que llama muchas veces a un procedimiento, puede
eliminar esta carga si quita la llamada al procedimiento y coloca el cuerpo del
procedimiento directamente dentro del bucle. Sin embargo, si coloca la misma
línea de código en varios bucles, el código duplicado aumenta el tamaño de la
aplicación. También aumenta las posibilidades de olvidarse de actualizar todas
las secciones repetidas cuando las modifique.

Del mismo modo, la llamada a un procedimiento ubicado dentro del propio
módulo es más rápida que una llamada al mismo módulo hecha desde un módulo .BAS
separado; si es necesario llamar al mismo procedimiento desde módulos múltiples,
dicha mejora quedará anulada.


Uso de constantes siempre que sea posible

El empleo de constantes hace que la aplicación sea más rápida. Las constantes
también hacen que el código sea más legible y fácil de mantener. Si hay en el
código cadenas o números que no cambian, declárelos como constantes. Las
constantes se resuelven al compilar el programa, y el valor apropiado se escribe
en el código. Sin embargo, si emplea variables, cada vez que la aplicación
ejecuta y encuentra una variable, tiene que leer el valor actual de la
variable.

Siempre que sea posible, utilice las constantes intrínsecas del Examinador de
objetos en vez de crear las suyas propias. No tiene que preocuparse por incluir
módulos que contengan constantes que no se utilizan en la aplicación; cuando se
genera el archivo .exe, se quitan las constantes que no se utilizan.


Paso de argumentos no modificados con ByVal en lugar de ByRef

Cuando escriba procedimientos Sub o Function que incluyan
argumentos no modificados, es más rápido pasar los argumentos por valor
(ByVal) que por referencia (ByRef). En Visual Basic los argumentos
se pasan ByRef de forma predeterminada, pero muy pocos procedimientos
modifican los valores de sus argumentos. Si no necesita modificar los argumentos
dentro del procedimiento, defínalos ByVal, como en el ejemplo
siguiente:

Código [Seleccionar] Expandir

Private Sub DoSomething(ByVal strName As String, _
ByVal intAge As Integer)



Usar argumentos opcionales con tipo

Los argumentos opcionales con tipo pueden aumentar la velocidad de las
llamadas a procedimientos y funciones. En las versiones anteriores de Visual
Basic, los argumentos opcionales tenían que ser de tipo Variant. Si el
procedimiento tenía argumentos ByVal, como en el ejemplo siguiente, los
16 bytes de la variable Variant tenían que pasar a la pila.

Código [Seleccionar] Expandir

Private Sub DoSomething(ByVal strName As String, _
Optional ByVal vntAge As Variant, _
Optional ByVal vntWeight As Variant)


La función utiliza menos espacio de pila en cada llamada y mueve menos datos
en la memoria si utiliza argumentos opcionales con tipo:

Código [Seleccionar] Expandir

Private Sub DoSomething(ByVal strName As String, _
Optional ByVal intAge As Integer, _
Optional ByVal intWeight As Integer)


Los argumentos opcionales con tipo tienen un acceso más rápido que las
variables Variant y por añadidura recibirá un mensaje de error en tiempo
de compilación si pasa datos que no sean del tipo declarado.

Uso de colecciones

La posibilidad de definir y usar colecciones de objetos es una característica
muy eficaz de Visual Basic. Si bien las colecciones pueden ser muy útiles, debe
usarlas correctamente para obtener el mayor rendimiento:

 
• Utilice For Each...Next en lugar de For...Next.
• Evite usar los argumentos Before y After cuando agregue
    objetos a una colección.
• Utilice colecciones con claves en vez de matrices para los grupos de
    objetos de un mismo tipo.

Las colecciones le permiten iterar por ellas mediante un bucle
For...Next. Sin embargo, la construcción For Each...Next es más
legible y en muchos casos más rápida. El creador de la colección implementa la
iteración For Each...Next, de modo que la velocidad real variará entre un
objeto de colección y otro. Sin embargo, For Each...Next raramente será
más lento que For...Next, puesto que la implementación más simple es una
iteración lineal del estilo For...Next. En algunos casos, el
implementador puede usar una implementación más sofisticada que la iteración
lineal y, por tanto, For Each...Next puede ser mucho más rápido.
Es más rápido agregar objetos a una colección si no utiliza los argumentos
Before y After. Estos argumentos requieren que Visual Basic busque
otro objeto de la colección antes de agregar el nuevo.

Cuando tiene un grupo de objetos de un mismo tipo, puede administrarlos
dentro de una colección o de una matriz (si son de distintos tipos, la colección
es la única opción posible). Desde el punto de vista de la velocidad, la
elección depende de cómo piensa tener acceso a los objetos. Si puede asociar una
clave única a cada objeto, la colección es la opción más rápida. Usar una clave
para obtener un objeto de una colección es más rápido que recorrer una matriz de
forma secuencial. Sin embargo, si no tiene dichas claves y, por tanto, tiene que
recorrer siempre todos los objetos, la matriz es la mejor opción. Las matrices
se recorren secuencialmente con más rapidez que las colecciones.

Para números reducidos de objetos, las matrices utilizan menos memoria y
suelen tener un acceso más rápido. El número de objetos a partir del cual las
colecciones son más eficientes que las matrices es aproximadamente 100; sin
embargo, esto puede variar dependiendo de la velocidad del procesador y la
memoria disponible.

[Optimizar la velocidad]

Optimizar la velocidad

La velocidad suele ser un factor determinante en la satisfacción y la impresión general de los usuarios respecto a una aplicación. Por desgracia, muchas de las cosas que influyen en la velocidad de una aplicación están fuera del control del programador: la velocidad del procesador, la falta de memoria o la velocidad de las conexiones de datos. Por esta razón, suele ser necesario optimizar las aplicaciones para que se ejecuten con mayor rapidez (o al menos para que lo parezca).

Las optimizaciones de velocidad puede dividirse en tres categorías generales: velocidad real (el tiempo real empleado en los cálculos y en la ejecución del código), velocidad de presentación (el tiempo empleado en la presentación de gráficos o en dibujar la pantalla) y velocidad percibida (la velocidad aparente de su aplicación). Los tipos de optimizaciones que usará realmente dependerán del tipo y el propósito de la aplicación, y que no todas las optimizaciones son adecuadas o beneficiosas en todos los casos.

Como ocurre con cualquier tipo de optimización, tiene que contrastar las posibles ventajas con los costos. No tiene ningún sentido pasar horas optimizando una rutina a la que raramente se llama. Determine las áreas donde las mejoras de velocidad beneficiarán a la mayoría de los usuarios (que apreciarán esas mejoras), como el tiempo de carga inicial de la aplicación.

[Descripción de la optimización]

Descripción de la
optimización

Se podría decir que la optimización es, a la vez, una ciencia y un arte. La
ciencia son las técnicas de optimización; el arte consiste en determinar dónde y
cuándo se deben aplicar las optimizaciones. Por definición, la optimización es
"el proceso de producir programas más eficientes (más pequeños y/o más rápidos)
mediante la selección y el diseño de estructuras de datos, algoritmos y
secuencias de instrucciones".

Es un error muy común considerar que la optimización es un proceso que tiene
lugar al final del ciclo de programación. Para crear una aplicación
verdaderamente optimizada, tiene que optimizarla mientras la desarrolla. Debe
elegir los algoritmos cuidadosamente, sopesar la velocidad con el tamaño y otras
limitaciones; debe formular hipótesis sobre qué partes de la aplicación serán
rápidas o lentas, grandes o pequeñas, y debe comprobar estas hipótesis a medida
que avanza.

El primer paso del proceso de optimización es determinar un objetivo. Puede
optimizar muchas y diferentes características de los programas:

 
• Velocidad real (la rapidez con que la aplicación calcula o realiza otras
    operaciones).
• Velocidad de presentación (la rapidez con que la aplicación dibuja en la
    pantalla).
• Velocidad percibida (la rapidez con que la aplicación parece ejecutarse;
    suele estar relacionada con la velocidad de presentación, pero no siempre con
    la velocidad real).
• Tamaño en memoria.
• Tamaño de los gráficos (afecta directamente al tamaño en memoria, pero
    suele tener ramificaciones adicionales cuando trabaja en Microsoft Windows).
   

Sin embargo, raras veces puede optimizar varias características. Normalmente,
una técnica que optimiza el tamaño compromete la velocidad; de igual forma, una
aplicación con velocidad optimizada suele ser mayor que sus equivalentes más
lentas. Por este motivo, las técnicas de optimización recomendadas para un área
pueden contradecir las sugerencias de otra.

Es importante observar que la optimización no es siempre beneficiosa en todos
los aspectos. Algunas veces, los cambios realizados para aumentar la velocidad o
reducir el tamaño de su aplicación producen un código más difícil de mantener o
de depurar. Algunas técnicas de optimización contradicen las reglas del código
estructurado, lo que puede suponer algún problema cuando amplíe su aplicación en
el futuro o cuando la incorpore a otros programas.

Al diseñar la estrategia de optimización de la aplicación debe tener en
cuenta tres factores: saber qué optimizar, saber dónde optimizar y saber cuándo
dejar de optimizar.


Saber qué optimizar: comprender el problema real

Si no tiene claros sus objetivos, puede desperdiciar mucho tiempo optimizando
cosas sin importancia. Sus objetivos tienen que estar basados en las necesidades
y expectativas de los usuarios. Por ejemplo, la velocidad puede ser un factor
determinante en el cálculo de los impuestos de ventas en una aplicación de punto
de venta, mientras que el tamaño tendrá más importancia si va a transferirse la
aplicación por Internet. La clave de la elección de una buena estrategia de
optimización es saber el problema real que tiene que afrontar la
optimización.

Aunque su estrategia de optimización tendrá un objetivo concreto, es muy útil
pensar en la optimización durante el proceso de desarrollo. Al escribir código,
puede aprender mucho si simplemente repasa el código y se detiene a pensar en lo
que está sucediendo realmente. Puede que olvide que establecer propiedades
desencadena eventos y si hay una cantidad grande de código en los procedimientos
de evento, una inofensiva línea puede provocar tremendos retrasos en el
programa. Incluso si su objetivo principal es el tamaño, algunas veces puede
implementar las optimizaciones de velocidad sin aumentar el tamaño del
código.


Saber dónde optimizar: máximas ventajas con el mínimo esfuerzo

Si es como la mayoría de los programadores, no dispondrá de tiempo suficiente
para optimizar todas las partes de la aplicación. Algunas veces es útil pensar
en tener un "presupuesto para optimización". Después de todo, el tiempo
adicional supone un costo más de la programación. ¿Dónde puede emplear el tiempo
para obtener el máximo beneficio de esta inversión? Obviamente, se concentrará
en las áreas que parecen ser las más lentas o las más grandes, pero para obtener
los mejores resultados de su esfuerzo preferirá concentrarse en la parte del
código donde produzca una gran diferencia con poco trabajo.

Por ejemplo, si la velocidad es su objetivo principal, los cuerpos de los
bucles son un buen sitio por donde empezar. Si mejora la velocidad de ejecución
de las operaciones de un bucle, esa mejora se multiplicará por el número de
veces que se ejecute el bucle. En los bucles con un gran número de iteraciones,
una operación de cadenas menos puede suponer una gran diferencia. Este mismo
principio puede aplicarse frecuentemente a las subrutinas.


Saber cuándo dejar de optimizar: comparar los resultados

En algunas ocasiones no vale la pena optimizar. Por ejemplo, escribir una
rutina de ordenación muy cuidada y muy rápida no tiene sentido si sólo va a
ordenar una docena de elementos. Puede ordenar elementos si los agrega a un
cuadro de lista ordenado y después los lee en orden. Este método es totalmente
ineficiente para grandes cantidades de elementos, pero para cantidades reducidas
es tan rápido como cualquier otro método y el código es admirablemente sencillo
(si bien un tanto confuso).

Hay otros casos en que la optimización es un esfuerzo vano. Si la aplicación
está relacionada con la velocidad del disco o de la red, poco puede hacer en el
código para aumentar la velocidad. En su lugar, tiene que pensar cómo hacer que
los retrasos sean menos problemáticos para los usuarios: barras de progreso para
indicarles que el programa no está  bloqueado, pasar datos a la memoria
caché para que los retrasos no sean tan frecuentes, permitir el uso de otros
programas en las esperas, etc.

[Optimizar Aplicaciones (Primera Parte)]

Optimizar Aplicaciones (Primera Parte)

Buscar el rendimiento y la compatibilidad

En un mundo ideal, los usuarios de sus aplicaciones dispondrían de un equipo con el procesador más rápido posible, gran cantidad de memoria, espacio de disco ilimitado y una conexión de red extremadamente rápida. La realidad indica que para la mayoría de los usuarios, el rendimiento real de una aplicación está condicionado por uno o varios de los factores anteriores. A medida que se crean aplicaciones mayores y más sofisticadas, la cantidad de memoria que consumen las aplicaciones y la velocidad con la que se ejecutan se hacen mayores. Es posible que decida optimizar su aplicación haciéndola más pequeña y acelerando los cálculos y las presentaciones.

Al diseñar y escribir el código de su aplicación, dispone de varias técnicas para optimizar el rendimiento. Algunas técnicas pueden ayudarle a que la aplicación sea más rápida, otras a que sea más pequeña. En este capítulo aprenderá algunos de los trucos de optimización más comunes que puede usar en sus propias aplicaciones.

Visual Basic comparte la mayor parte de las características del lenguaje con Visual Basic para aplicaciones, que se incluye en Microsoft Office y en otras muchas aplicaciones. Visual Basic, Scripting Edition (VBScript), un lenguaje de comandos para Internet, también es un subconjunto del lenguaje Visual Basic. Si también va a programar con Visual Basic para aplicaciones o con VBScript, probablemente deseará compartir partes de código entre estos lenguajes.

Ve a:

http://www16.brinkster.com/eduroam/api/default.asp?pag=cap3

En esta URL se explican las APIs gráficas. Si te fijas bien la url termina en cap3, pues bien, hay desde cap1 hasta cap12, esto lo tengo en la recopilación de posts interesantes. Mi intención no es meramente que encuentres la solución a tu problema, sino que sólamente te estoy comentando porque me parece un buen manual, y no sólo explica APIs, sino también incluye aspectos técnicos de Windows. Quizá te sea útil, sino ve a

http://msdn.microsoft.com

Hilsener.

[---]

---
Con este post pretendo recopilar no sólo posts, sino enlaces a publicaciones de este foro donde se traten asuntos con respecto a las preguntas y temas más frecuentes de Visual Basic; esto con la intención de evitar las repetitivas de posts donde se formulan cuestiones que poca o nula es su importancia. En este foro quiero calidad, no usuarios que no se preocupan por aprender, ni al menos buscar. Antes de ponerse a vociferar lean los temas que están pegados.

Las temáticas han sido ordenadas según pienso yo es un buen orden a seguir, inicialmente están los aspectos básicos de Visual Basic, y seguido irá un material algo más avanzado (gradualmente). Cabe mencionar que este enlace está en constante actualización por mi parte, tanto actualización como reorganización, y si alguien desea sugerir un enlace, hágalo enviándome un mensaje privado.

Rutinas_interesantes


Actualizado: Sábado, 4 de agosto del 2007.



Introito

¿Visual Basic 6 o Visual Basic .NET?
http://foro.elhacker.net/index.php/topic,52926.0.html

¿Se va a quedar obsoleto Visual Basic?
http://foro.elhacker.net/index.php/topic,67402.0.html

¿De verdad que merece la pena Visual Basic?
http://foro.elhacker.net/index.php/topic,48156.0.html

Aprenda Visual Basic 6.0 como si estuviera en primero
http://www.elhacker.org/index.php?Ver=Articulo&Id=164

Curso Básico de Programación en Visual Basic
http://www.elhacker.org/index.php?Ver=Articulo&Id=272



Descargas

Descargar Visual Basic
http://foro.elhacker.net/index.php/topic,58439.0.html

VB6 portable:
http://foro.elhacker.net/programacion_vb/visual_basic_60_portable_genera_exes-t236223.0.html

En KaZaA no encuentro el visual basic 6, ¿dónde lo puedo descargar??
http://foro.elhacker.net/index.php/topic,10588.0.html

¿De donde puedo bajar el visual basic 6.0?
http://foro.elhacker.net/index.php/topic,10450

¿Donde bajar Visual Basic .NET?
http://foro.elhacker.net/index.php/topic,53533

¿Cuál es el mejor compilador para VB además de el que incluye por defecto el del entorno?
http://foro.elhacker.net/index.php/topic,76284.0.html

Visual Basic 6 Runtime Files
http://visual-basic-6-runtime-files.uptodown.com/

Visual Basic Runtime Files
http://www.programas.us/bajar/339

Programazo: Code Advisor 6.0
http://foro.elhacker.net/index.php/topic,160152.0.html
/*Esta aplicación se integra dentro de Visual Basic 6.0
 y nos permite con un simple click de ratón analizar todo
 nuestro código fuente en busca de errores o mejoras.*/

Descargar archivos DirectX para Visual
http://foro.elhacker.net/index.php/topic,69509.0.html

Hasta donde tengo comprendido el RichTextBox es un control ya prediseñado (obviamente) y con sus respectivas propiedades y métidos que no puedes cambiar, si acaso puedes arreglar el formato para que parezca resaltado; en dado caso lo que puedes hacer es que se vea en negrita y al mismo tiempo en un tamaño de letra uno o dos puntos mayores.

Hilsener.

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.

Hilsener.