Más reflexiones sobre el rendimiento

El rendimiento es un conjunto de propiedades cuantificables de un ejecutor.

En este contexto, el rendimiento no es la ejecución de una acción en sí misma; es qué tan bien se desempeña algo o alguien. Por lo tanto, usamos el adjetivo performant.

Aunque la parte de qué tan bien puede, en general, describirse en lenguajes naturales, en nuestro alcance limitado, el enfoque está en algo que es cuantificable como un número real. Los números reales incluyen enteros y binarios 0/1 como casos especiales. Las descripciones en lenguaje natural siguen siendo muy importantes. Por ejemplo, un artículo de noticias que critique duramente el rendimiento de Flutter utilizando solo palabras sin ningún número (un valor cuantificable) podría seguir siendo significativo, y podría tener grandes impactos. El alcance limitado se elige únicamente debido a nuestros recursos limitados.

La cantidad requerida para describir el rendimiento a menudo se denomina métrica.

Para navegar a través de innumerables problemas y métricas de rendimiento, puedes categorizar según los ejecutores.

Por ejemplo, la mayor parte del contenido de este sitio web trata sobre el rendimiento de las aplicaciones Flutter, donde el ejecutor es una aplicación Flutter. El rendimiento de la infraestructura también es importante para Flutter, donde los ejecutores son bots de compilación y ejecutores de tareas de CI: afectan en gran medida la rapidez con la que Flutter puede incorporar cambios de código para mejorar el rendimiento de la aplicación.

Aquí, el alcance se amplió intencionalmente para incluir otros problemas de rendimiento además de los problemas de rendimiento de la aplicación porque pueden compartir muchas herramientas independientemente de quiénes sean los ejecutores. Por ejemplo, el rendimiento de la aplicación Flutter y el rendimiento de la infraestructura podrían compartir el mismo panel y mecanismos de alerta similares.

Ampliar el alcance también permite incluir ejecutores que tradicionalmente son fáciles de ignorar. El rendimiento de los documentos es un ejemplo de ello. El ejecutor podría ser un documento de la API del SDK, y una métrica podría ser: el porcentaje de lectores que encuentran útil el documento de la API.

Responder a esta pregunta no solo es crucial para validar el trabajo en rendimiento, sino también para guiar el trabajo de rendimiento con el fin de ser más útil. La respuesta a "¿por qué es importante el rendimiento?" a menudo también es la respuesta a "¿cómo es útil el rendimiento?"

Dicho de forma sencilla, el rendimiento es importante y útil porque, en este alcance, el rendimiento debe tener propiedades o métricas cuantificables. Esto implica:

1. Un reporte de rendimiento es fácil de consumir.
2. El rendimiento tiene poca ambigüedad.
3. El rendimiento es comparable y convertible.
4. El rendimiento es justo.

No es que el no rendimiento, o las descripciones o problemas no medibles no sean importantes. Tienen como objetivo destacar los escenarios donde el rendimiento puede ser más útil.

Las métricas de rendimiento son números. Leer un número es mucho más fácil que leer un pasaje de texto. Por ejemplo, probablemente a un ingeniero le tome 1 segundo consumir la calificación de rendimiento como un número del 1 al 5. Probablemente le tome al mismo ingeniero al menos 1 minuto leer el resumen completo de comentarios de 500 palabras.

Si hay muchos números, es fácil resumirlos o visualizarlos para un consumo rápido. Por ejemplo, puedes consumir rápidamente millones de números mirando su histograma, promedio, cuantiles, etcétera. Si una métrica tiene un historial de miles de puntos de datos, puedes trazar fácilmente una línea de tiempo para leer su tendencia.

Por otro lado, tener un número n de textos de 500 palabras garantiza casi un costo de tiempo n para consumir esos textos. Sería una tarea abrumadora analizar miles de descripciones históricas, cada una de 500 palabras.

Otra ventaja de tener el rendimiento como un conjunto de números es su falta de ambigüedad. Cuando quieres que una animación tenga un rendimiento de 20 ms por fotograma o 50 fps, hay poco espacio para diferentes interpretaciones sobre los números. Por otro lado, para describir la misma animación en palabras, alguien podría decir que es buena, mientras que otra persona podría quejarse de que es mala. De manera similar, la misma palabra o frase podría ser interpretada de manera diferente por diferentes personas. Tú podrías interpretar que una tasa de fotogramas aceptable es de 60 fps, mientras que otra persona podría interpretar que es de 30 fps.

Los números aún pueden tener ruido. Por ejemplo, el tiempo medido por fotograma podría ser el tiempo de cálculo real de este fotograma, más una cantidad aleatoria de tiempo (ruido) que la CPU/GPU dedica a algún trabajo no relacionado. Por lo tanto, la métrica fluctúa. Sin embargo, no hay ambigüedad sobre lo que significa el número. And también existen teorías rigurosas y herramientas de prueba para manejar dicho ruido. Por ejemplo, podrías tomar múltiples mediciones para estimar la distribución de una variable aleatoria, o podrías tomar el promedio de muchas mediciones para eliminar el ruido mediante la ley de los grandes números.

Los números de rendimiento no solo tienen significados inequívocos, sino que también tienen comparaciones inequívocas. Por ejemplo, no hay duda de que 5 es mayor que 4. Por otro lado, podría ser subjetivo determinar si excelente es mejor o peor que soberbio. De manera similar, ¿podrías determinar si épico es mejor que legendario? De hecho, la frase strongly exceeds expectations podría ser mejor que superb en la interpretación de alguien. Solo se vuelve inequívoco y comparable después de una definición que asigne a "supera con creces las expectativas" un 4 y a "soberbio" un 5.

Los números también se pueden convertir fácilmente usando fórmulas y funciones. Por ejemplo, 60 fps se pueden convertir a 16.67 ms por fotograma. El tiempo de renderizado de un fotograma x (ms) se puede convertir en un indicador binario isSmooth = [x <= 16] = (x <= 16 ? 1 :0). Dicha conversión se puede combinar o encadenar, por lo que puedes obtener una gran variedad de cantidades usando una sola medición sin ningún ruido o ambigüedad adicional. La cantidad convertida se puede usar luego para comparaciones y consumos adicionales. Tales conversiones son casi imposibles si estás tratando con lenguajes naturales.

Si los problemas dependen de palabras detalladas para ser descubiertos, entonces se da una ventaja injusta a las personas que son más detalladas (más dispuestas a charlar o escribir) o a aquellas que están más cerca del equipo de desarrollo, quienes tienen un mayor ancho de banda y menor costo para charlar o tener reuniones cara a cara.

Al tener las mismas métricas para detectar problemas sin importar qué tan lejos o qué tan silenciosos sean los usuarios, podemos tratar todos los problemas de manera justa. Eso, a su vez, nos permite enfocarnos en los problemas correctos que tienen un mayor impacto.

A continuación se resumen los 4 puntos discutidos aquí, desde una perspectiva ligeramente diferente:

1. Haz que las métricas de rendimiento sean fáciles de consumir. No abrumes a los lectores con una gran cantidad de números (o palabras). Si hay muchos números, intenta resumirlos en un conjunto más pequeño de números (por ejemplo, resumir muchos números en un solo promedio). Solo notifica a los lectores cuando los números cambien significativamente (por ejemplo, alertas automáticas sobre picos o regresiones).

2. Haz que las métricas de rendimiento sean lo más inequívocas posible. Define la unidad que utiliza el número. Describe con precisión cómo se mide el número. Haz que el número sea fácilmente reproducible. Cuando haya mucho ruido, intenta mostrar la distribución completa o elimina el ruido tanto como sea posible agregando muchas mediciones ruidosas.

3. Haz que sea fácil comparar el rendimiento. Por ejemplo, proporciona una línea de tiempo para comparar la versión actual con la versión anterior. Proporciona formas y herramientas para convertir una métrica en otra. Por ejemplo, si podemos convertir tanto el aumento de memoria como las caídas de fps en el número de usuarios perdidos o los ingresos perdidos en dólares, entonces podemos compararlos y hacer una compensación informada.

4. Haz que las métricas de rendimiento monitoreen una población que sea lo más amplia posible, para que nadie se quede atrás.