Aprender a entender el rendimiento de un sistema en ejecución es inevitable por la misma razón que aprender a depurar. Incluso si comprendes perfectamente el costo preciso del código que escribes, tu código hará llamadas a otros sistemas de software sobre los que tienes poco control o visibilidad. Sin embargo, en la práctica, los problemas de rendimiento son un poco diferentes y un poco más fáciles que la depuración en general.
Supongamos que tú o tus clientes consideran que un sistema o un subsistema es demasiado lento. Antes de intentar acelerarlo, debes construir un modelo mental de por qué es lento. Para hacer esto, puedes utilizar una herramienta de perfilado o un buen registro para descubrir dónde se está gastando realmente el tiempo u otros recursos. Existe un famoso dicho que establece que el 90% del tiempo se gastará en el 10% del código. Añadiría a eso la importancia del gasto de entrada/salida (E/S) en los problemas de rendimiento. A menudo, la mayor parte del tiempo se gasta de alguna manera en la E/S. Encontrar la E/S costosa y el 10% costoso del código es un buen primer paso para construir tu modelo mental.
Hay muchas dimensiones para medir el rendimiento de un sistema informático y muchos recursos consumidos. El primer recurso a medir es el tiempo del reloj de pared, el tiempo total que pasa para la computación. Registrar el tiempo del reloj de pared es particularmente valioso porque puede informar sobre circunstancias impredecibles que surgen en situaciones donde otro perfilado es impracticable. Sin embargo, esto no siempre representa toda la imagen. A veces, algo que tarda un poco más pero no consume tantos segundos del procesador será mucho mejor en el entorno informático con el que realmente tienes que lidiar. De manera similar, la memoria, el ancho de banda de red, el acceso a la base de datos u otros servidores pueden, al final, ser mucho más costosos que los segundos del procesador.
La competencia por recursos compartidos que están sincronizados puede causar bloqueo y privación. El bloqueo es la imposibilidad de avanzar debido a una sincronización incorrecta o demandas de recursos. La privación es la incapacidad para programar adecuadamente un componente. Si se puede anticipar de alguna manera, es mejor tener una forma de medir esta competencia desde el inicio de tu proyecto. Incluso si esta competencia no ocurre, es muy útil poder afirmar eso con confianza.