¿Cómo solucionar problemas de rendimiento?

La mayoría de los proyectos de software pueden acelerarse de 10 a 100 veces con relativamente poco esfuerzo en comparación con la velocidad que tienen al momento de su lanzamiento inicial. Bajo la presión del tiempo de llegada al mercado, es sabio y efectivo elegir una solución que haga el trabajo de manera simple y rápida, aunque menos eficientemente que alguna otra solución. Sin embargo, el rendimiento es parte de la usabilidad y a menudo debe considerarse más cuidadosamente en algún momento.

La clave para mejorar el rendimiento de un sistema muy complicado es analizarlo lo suficientemente bien como para encontrar los cuellos de botella, o los lugares donde se consumen la mayoría de los recursos. No tiene mucho sentido optimizar una función que representa solo el 1% del tiempo de computación. Como regla general, debe pensarlo detenidamente antes de hacer cualquier cosa a menos que piense que hará que el sistema o una parte significativa de él sea al menos el doble de rápido. Por lo general, hay una manera de hacerlo. Considere el esfuerzo de prueba y aseguramiento de la calidad que requerirá su cambio. Cada cambio conlleva una carga de prueba, por lo que es mucho mejor tener algunos cambios importantes.

Después de haber logrado una mejora del doble en algo, es necesario al menos reconsiderar y tal vez volver a analizar para descubrir el siguiente cuello de botella más costoso en el sistema y abordarlo para obtener otra mejora del doble.

A menudo, los cuellos de botella en el rendimiento son un ejemplo de contar vacas contando patas y dividiendo por cuatro, en lugar de contar cabezas. Por ejemplo, he cometido errores como no proporcionar a un sistema de base de datos relacional un índice adecuado en una columna que consulto con frecuencia, lo que probablemente lo hizo al menos 20 veces más lento. Otros ejemplos incluyen realizar E/S innecesaria en bucles internos, dejar declaraciones de depuración que ya no son necesarias, asignación de memoria innecesaria y, en particular, el uso inexperto de bibliotecas y otros subsistemas que a menudo están mal documentados en cuanto al rendimiento. Este tipo de mejora a veces se llama fruto de bajo hanging, lo que significa que se puede recoger fácilmente para proporcionar algún beneficio.

¿Qué haces cuando comienzas a quedarte sin "fruto de bajo colgado"? Bueno, puedes alcanzar más alto o derribar el árbol. Puedes seguir haciendo pequeñas mejoras o puedes rediseñar seriamente un sistema o un subsistema. (Esta es una gran oportunidad para usar tus habilidades como buen programador, no solo en el nuevo diseño sino también en convencer a tu jefe de que es una buena idea). Sin embargo, antes de argumentar a favor del rediseño de un subsistema, debes preguntarte si tu propuesta lo mejorará cinco a diez veces.

Siguiente ¿Cómo optimizar bucles?