Medir antes de optimizar
La regla que ordena toda la fase de rendimiento: qué medir, con qué herramientas, y por qué la intuición sobre dónde está el problema falla casi siempre.
Los cuatro sitios
Y la observación que justifica el nivel: la intuición apunta casi siempre al core —«Rust es rápido, luego el problema es mío»— y en la práctica el segundo sitio es el más frecuente. Cien llamadas al puente donde debería haber una explican más lentitud que casi cualquier consulta.
El orden de medición
El paso 2 antes que el 3 y el 4 es lo que ahorra tiempo: es el más barato de hacer y el que más veces da la respuesta.
No engañarse con la máquina de desarrollo
Cuatro formas de medir mal, y las cuatro son fáciles de cometer:
- Medir en modo de desarrollo. El core sin optimizar puede ser órdenes de magnitud más lento, y el frontend sin compilar también. Las mediciones se hacen sobre la compilación de publicación, siempre.
- Medir con tus datos. Doscientas filas no son doscientas mil. Nivel 42.5.
- Medir la segunda vez. Todo está en caché: el fichero, las páginas de la base, la conexión. La primera vez es la que el usuario vive, sobre todo en el arranque. Nivel 57.
- Y medir en tu máquina. Que probablemente es mejor que la mediana de las de tus usuarios, con disco más rápido.
El tercero es el que más engaña en el arranque y tiene arreglo: hay formas de vaciar las cachés del sistema entre mediciones, y merece usarlas.
Fijar el número
Y la disciplina que hace que esto sirva de algo:
- Anota el número antes. Sin él, cualquier cambio «parece» que mejora.
- Mide varias veces. Tres o cinco, y quédate con la mediana: la variación entre ejecuciones es grande.
- Y anota el número después, en el mismo mensaje de commit o en una nota. Es lo que permite saber, meses después, si algo se degradó y cuándo.
Y decide un presupuesto: cuánto puede tardar el arranque, cuánto una acción normal, cuánta memoria en reposo. Un número escrito convierte «va lento» en una comprobación.