|
Título: NekroAyuda: Optimizar aplicaciones I: Buscar el rendimiento y la compatibilidad Publicado por: NekroByte en 24 Mayo 2005, 04:51 am 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. Título: Descripción de la optimización Publicado por: NekroByte en 24 Mayo 2005, 04:51 am 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:
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. Título: Optimizar la velocidad Publicado por: NekroByte en 24 Mayo 2005, 04:52 am 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. Título: Optimizar el código Publicado por: NekroByte en 24 Mayo 2005, 04:55 am 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:
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: Dim X, Y, Z As Long Escritas de esta manera, las tres variables son de tipo Long: Código: 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.
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: For i = 0 To 10 Escrito de esta manera, es mucho más rápido: Código: picLeft = picPallete.Left De igual manera, este código . . . Código: Do Until EOF(F) . . . es mucho más lento que éste: Código: Do Until EOF(F) Sin embargo, este código hace el mismo trabajo y es aún más rápido: Código: 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: Private Sub DoSomething(ByVal strName As String, _ 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: Private Sub DoSomething(ByVal strName As String, _ 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: Private Sub DoSomething(ByVal strName As String, _ 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:
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. Título: Optimizar la velocidad de presentación Publicado por: NekroByte en 24 Mayo 2005, 04:56 am 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 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: Sub Form_Resize () 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: Sub Form_Resize () 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. Título: Optimizar la velocidad percibida Publicado por: NekroByte en 24 Mayo 2005, 04:57 am 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 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 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: Sub Form_Load() 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. Título: Medir el rendimiento Publicado por: NekroByte en 24 Mayo 2005, 04:58 am 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
Código: Private Sub Command1_Click() [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. Título: Optimizar el tamaño Publicado por: NekroByte en 24 Mayo 2005, 04:59 am 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. Título: Reducir el tamaño del código Publicado por: NekroByte en 24 Mayo 2005, 05:00 am 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:
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 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: 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: Private Sub Label1_LostFocus() 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: Erase MiMatriz Mientras Erase elimina completamente la matriz, ReDim Preserve reduce su tamaño sin perder el contenido: Código: 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: 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: Private rs As New RecordSet 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". Título: Recortar los gráficos Publicado por: NekroByte en 24 Mayo 2005, 05:02 am 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 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: Picture = LoadPicture("C:\Windows\Chess.bmp")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: 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: 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: midib.AutoRedraw = True ' Activa 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. Título: Aplicaciones segmentadas Publicado por: NekroByte en 24 Mayo 2005, 05:03 am 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:
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:
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:
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:
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:
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. Título: Optimizar los objetos Publicado por: NekroByte en 24 Mayo 2005, 05:04 am 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:
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: Dim X As New MiObjeto O bien, su equivalente: Código: Dim X As 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: ' Referencia a la celda A1 de Sheet1 del primer libro 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: ' Referencia a la celda A1 de Sheet1 del primer libro 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: ' Referencia a la celda A1 de la hoja activa del 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: Dim xlRange As Object Visual Basic proporciona la estructura With...End With para establecer un objeto implícito dentro del código: Código: With Application.ActiveSheet.Cells(1,1) 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. Título: Aplicaciones compiladas frente a interpretadas Publicado por: NekroByte en 24 Mayo 2005, 05:06 am 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.
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. Título: Compatibilidad con otras aplicaciones de Microsoft Publicado por: NekroByte en 24 Mayo 2005, 05:09 am 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. Título: Tema cerrado. Publicado por: NekroByte en 24 Mayo 2005, 05:11 am 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. |