CursosOnlineEnDirecto-Benowu

Cómo Corregir Problemas de Desempeño

Como corregir problemas de desempeño

La mayoría de los proyectos de software pueden hacerse con relativamente poco esfuerzo de 10 a 100 veces más rápido de lo que son la primera vez que son liberados. Bajo la presión del tiempo de mercadeo, es tan sabio como efectivo elegir una solución que obtenga el trabajo hecho simple y rápidamente, pero menos eficiente que alguna otra solución. Sin embargo, el desempeño es una parte de la usabilidad, y a menudo debe eventualmente ser considerado más cuidadosamente.

La clave para mejorar el desempeño de un sistema muy complicado es analizarlo lo suficientemente bien para encontrar los cuellos de botella, o lugares donde se consumen la mayoría de los recursos. No tiene mucho sentido optimizar una función
que cuenta solamente para el 1% del tiempo de cómputo. Como una regla de ganadores deberías pensar cuidadosamente antes de hacer algo a menos que pienses que va a hacer al sistema o a una parte significativa de él al menos dos veces más rápida. Usualmente hay una forma de hacer esto. Considera los tests y los esfuerzos de aseguramiento de la calidad que tu cambio requerirá. Cada cambio trae una prueba aparejada con él, de tal manera que es mucho mejor tener unos cuantos grandes cambios.

Después de que has hecho una mejora de dos pliegues en algo, necesitas al menos repensar y quizá reanalizar para descubrir el siguiente cuello de botella más costoso en el sistema, y atacar eso para obtener otra mejora de dos pliegues.

A menudo, los cuellos de botella en el desempeño serán un ejemplo de contar vacas mediante el conteo de piernas y dividiendo entre cuatro, en lugar de contar cabezas. Por ejemplo, he cometido errores tales como fallar al proveer un sistema de base de
datos relacional con un índice apropiado sobre una columna que observé mucho, lo cual probablemente la hizo al menos 20 veces más lenta. Otros ejemplos incluyen hacer E/S innecesaria en ciclos internos, dejar sentencias de depuración que no se
necesitaban más, asignación de memoria innecesaria, y, en particular, uso inexperto de bibliotecas y otros subsistemas que a menudo están pobremente documentados con respecto al desempeño. Este tipo de mejora es a veces llamada fruta de cuelgue
bajo, que significa que puede ser fácilmente elegida para proveer algún beneficio.

¿Qué haces cuando empiezas a quedarte sin frutas de cuelgue bajo? Bien, puedes alcanzar las más altas, o derribar el árbol. Puedes continuar haciendo pequeñas mejoras o puedes rediseñar seriamente un sistema o un subsistema. (Esta es una
gran oportunidad para usar tus habilidades de buen programador, no solamente en el nuevo diseño sino también en convencer a tu jefe que esta es una buena idea.) Sin embargo, antes de que argumentes por el rediseño de un subsistema, deberías preguntarte a ti mismo si tu propuesta lo hará o no de cinco a diez veces mejor.

 

Fuente:

Cómo Ser Un Programador: Un Resumen
Corto, Comprensivo y Personal
por Robert L. Read

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Subir

Canal de aprender-libre.com

Reciba todas las publicaciones desde nuestro canal en Telegram

UNIRSE
CERRAR