Tu intuición sobre la lentitud suele equivocarse

Un médico que prescribe cirugía basándose en una corazonada, sin haber hecho nunca una prueba — seguro, rápido y, con demasiada frecuencia, operando algo que no era el problema.

Los desarrolladores son famosos por adivinar mal dónde se va el tiempo. La parte que crees lenta a menudo está bien; el verdadero culpable está en un sitio que nunca sospechaste — una función diminuta llamada un millón de veces, una llamada oculta a la base de datos.

Actuar por corazonada significa que optimizas lo que no toca, añades complejidad y el programa sigue siendo lento. El primer movimiento nunca es «arréglalo» — es averiguar adónde se va realmente el tiempo.

El mapa: 20 conceptos en siete grupos

Un mapa de metro: primero ves las líneas enteras, luego recorres estación por estación.

Los conceptos del curso se dividen en siete grupos — uno por capítulo. Primero, cómo medir. Luego, qué tipo de «rápido» necesitas. Después, el bottleneck y los arreglos clásicos para él. Y por último, cómo no dejarte engañar por el promedio, cuándo no optimizar y cómo llevar todo esto como un bucle.

Cómo leer este curso

Un mecánico no cambia piezas al azar: primero los instrumentos, luego un arreglo, luego una nueva prueba.

Cada concepto recibe el mismo tratamiento: su nombre en inglés (memorízalo — es el término de la documentación, los profilers y los paneles), una imagen de la vida cotidiana, un diagrama y una ficha con qué es, cómo funciona, ejemplo, trampa y relaciones.

La gran idea: el rendimiento no es una bolsa de trucos, es un método. Mide → encuentra el bottleneck → arregla esa única cosa → vuelve a medir → para al llegar al objetivo. Todo lo demás del curso son detalles dentro de ese bucle.

Profiling — encuentra el coste real

Una factura detallada que muestra exactamente adónde se fue el dinero, línea por línea — para que dejes de adivinar y veas que fue ese cargo, no los que suponías, el que se comió el presupuesto.

Un profiler es una herramienta que mide dónde gasta realmente el tiempo tu programa, función por función. Convierte «creo que esto es lento» en «esta función es el 80% del tiempo de ejecución». Con eso, arreglas lo que importa en lugar de lo que imaginabas.

Ya sea un profiler, logs de tiempos o tus métricas de observabilidad, el principio se mantiene: deja que la medición, no la intuición, te señale el problema.

Measure–Fix–Measure — mide, arregla, vuelve a medir

Un científico cambia una variable, repite el experimento y comprueba el resultado — nunca da por hecho que un cambio ayudó, siempre confirma que así fue.

El rendimiento es un bucle: mide para encontrar la parte lenta, cámbiala y vuelve a medir para confirmar que el cambio ayudó de verdad — y que no se limitó a mover el problema o a empeorarlo.

Sin la segunda medición estás adivinando si mejoraste algo, que es como las «optimizaciones» empeoran las cosas en silencio. Trata cada arreglo como una hipótesis que verificas — la misma disciplina que las evals para la IA o los tests para el código.

Latency — la espera por una sola cosa

Cuánto tarda un solo café desde el pedido hasta la taza — la experiencia de un cliente, medida de principio a fin.

La latency es cuánto tarda una operación de principio a fin — una petición, una carga de página, una consulta. Es lo que un usuario individual siente: la espera.

Cuando alguien dice «el sitio es lento», casi siempre se refiere a la latency — el retraso entre hacer algo y obtener una respuesta. Bajar la latency es hacer que cada cosa individual ocurra más rápido.

Throughput — cuánto manejas por segundo

Cuántos cafés sirve la cafetería entera en una hora — no cuánto tarda uno, sino el flujo total a través del local.

El throughput es cuánto trabajo maneja el sistema por unidad de tiempo — peticiones por segundo, trabajos por minuto. Tiene que ver con la capacidad total, no con la espera individual.

Un sistema puede tener un gran throughput (sirviendo a miles a la vez) mientras cada usuario aún espera un rato (latency alta), o latency baja pero capacidad limitada. Son objetivos distintos, y cuál persigues cambia lo que arreglas.

Batching — throughput a costa de latency

Una moto te lleva más rápido (latency baja); un autobús mueve a más gente por viaje (throughput alto). El mejor vehículo depende de lo que necesites.

Latency y throughput son independientes, y optimizar uno puede perjudicar al otro. El batching — agrupar el trabajo — suele subir el throughput pero añade latency, porque cada elemento espera al lote.

Así que tienes que decidir cuál importa aquí: una página de cara al usuario vive o muere por la latency; un pipeline de datos en segundo plano se preocupa por el throughput. Nombrar tu objetivo real evita que optimices el número que no le importa a tus usuarios.

Bottleneck — una parte lenta domina

Una cadena es tan fuerte como su eslabón más débil — reforzar los eslabones fuertes no sirve de nada; solo el débil decide si aguanta.

En la mayoría de los sistemas lentos, un único bottleneck se lleva la mayor parte del tiempo — una consulta, un servicio lento, un bucle malo. Todo lo demás ya es lo bastante rápido.

Por eso adivinar es tan inútil: toda la habilidad consiste en localizar el coste dominante, no en mejorar las partes rápidas.

Limiting Step — el sistema es tan rápido como su paso más lento

Una autopista despejada hasta que un carril cortado hace que todos los coches avancen a paso de tortuga — la velocidad de todo el viaje la marca ese único cuello de botella, no los tramos libres.

Una petición que pasa por diez pasos está limitada por el más lento — el limiting step. Acelerar los nueve pasos rápidos apenas mueve el total; el paso lento marca el ritmo. Así que apuntas al cuello de botella en concreto.

Y fíjate en que arreglar un bottleneck a menudo revela el siguiente: quita el paso más lento y aparece uno nuevo. El trabajo de rendimiento es encontrar y despejar, una y otra vez, lo que limita al sistema ahora mismo.

Amdahl's Law — optimizar en otro sitio es esfuerzo perdido

Sacar brillo al trofeo mientras el coche tiene un pinchazo — esfuerzo gastado donde no cambia nada, mientras lo que de verdad te detiene queda ignorado.

Optimiza una parte que es solo el 2% del tiempo de ejecución y lo máximo que ganarás es un 2%. Encuentra la parte que es el 80% y arreglarla lo transforma todo. Esta aritmética se llama ley de Amdahl: tu ganancia está limitada por la proporción de tiempo que ocupa la parte que aceleras.

El tiempo dedicado a optimizar cualquier cosa que no sea el bottleneck es, por definición, tiempo que no puede ayudar de forma significativa. A menudo empeora las cosas, añadiendo complejidad y errores por una ganancia invisible. La medición te impide optimizar con cariño la parte que entiendes y te obliga a ir a la que de verdad cuesta. Arregla el bottleneck, ignora el resto — hasta que el resto se convierta en el bottleneck.

Better Algorithm (Big-O) — un mejor algoritmo vence a una máquina más rápida

Dos rutas a la misma ciudad: un coche más rápido por la carretera larga y sinuosa pierde ante un coche más lento por el atajo recto. La ruta importa más que el motor.

Las mayores victorias suelen venir de un mejor algoritmo o estructura de datos, no de hardware más rápido ni de microajustes. Big-O describe cómo crece el tiempo al crecer la entrada. Un bucle O(n²) sustituido por una búsqueda en un mapa hash O(n) puede convertir minutos en milisegundos — un cambio que ninguna máquina más rápida igualaría.

Antes de optimizar lo pequeño, pregúntate si el enfoque es el equivocado. Una mejor forma, como muestra el curso de estructuras de datos, es la aceleración más barata y más grande que existe.

N+1 Query — demasiados viajes de ida y vuelta

Hacer veinte viajes distintos a la tienda para comprar una cosa cada vez, en lugar de uno solo con una lista — el trayecto, no la compra, se está comiendo tu tarde.

Una enorme cantidad de lentitud son demasiados viajes de ida y vuelta — llamadas repetidas a una base de datos o a un servicio, cada una barata por sí sola pero devastadora en masa.

El clásico es la N+1 query: traer una lista y luego hacer una consulta más por cada elemento, convirtiendo un viaje en cientos. El arreglo es traer en bloque — pedirlo todo de una vez. Reducir el número de viajes suele superar a acelerar cada uno, porque el viaje en sí es el coste.

Caching — no calcules lo mismo dos veces

Volver a cocinar una comida desde cero cada vez que alguien la pide, en lugar de mantener una olla caliente — el trabajo más rápido es el que no repites.

El caching — recordar un resultado costoso para no recalcularlo — es una de las mayores palancas que existen (tiene su propio curso).

La primera petición toma el camino lento y guarda el resultado; las siguientes lo obtienen de la memoria. El precio es memoria y el riesgo de servir datos desactualizados.

Doing Less — el trabajo más rápido es el que te saltas

No cocinar lo que nadie pidió, y no poner la mesa para veinte cuando han venido tres.

Otro clásico más — hacer menos. Calcula las cosas de forma perezosa (lazy), solo cuando de verdad hacen falta; evita cargar datos que no vas a usar; sáltate el trabajo cuyo resultado vas a tirar.

La operación más rápida es la que nunca ejecutas. A menudo la mejor optimización no es hacer el trabajo más rápido — es no hacerlo en absoluto.

Average — el promedio esconde los casos lentos

Una sala con nueve personas cómodas y una en llamas tiene una temperatura media agradable — la media borra el caso que de verdad importa.

Reportar el rendimiento como un promedio (la media) es peligrosamente tranquilizador: mezcla a la mayoría rápida con unos pocos lentos en un único número feliz. Pero los usuarios no viven el promedio — cada usuario vive su petición, y los lentos sienten cada milisegundo.

Un tiempo de respuesta medio de 200 ms puede esconder que uno de cada veinte usuarios espera cinco segundos. La media te dice que el sistema va bien mientras una parte real de tus usuarios sufre.

Percentiles — p50 y p99 muestran la experiencia real

Un informe que no dice solo la espera típica sino «el 1% más lento de la gente esperó esto» — nombra las malas experiencias en lugar de diluirlas en un promedio.

Los percentiles capturan lo que el promedio esconde. p50 (la mediana) es el caso típico — la mitad son más rápidos. p99 es la cola lenta — el 99% son más rápidos, así que es más o menos la peor experiencia que se encuentra un usuario real.

Vigilar el p99, y no solo el promedio, es como ves a los usuarios que de verdad están sufriendo. La cola es donde vive el dolor, y los percentiles son la forma de hacerla visible.

Tail Latency — lo que los usuarios recuerdan

Una comida terrible en un restaurante pesa más en la memoria de alguien que una docena de comidas correctas — las peores experiencias, no el promedio, moldean cómo te juzga la gente.

Las peticiones lentas — la tail latency — moldean de forma desproporcionada cómo perciben los usuarios tu producto, porque una mala experiencia se queda grabada.

Y a escala, la cola afecta a más gente de lo que parece: si cada página hace muchas llamadas, la probabilidad de que al menos una sea lenta crece muy rápido, así que casi todos los usuarios acaban sintiendo la cola. Por eso los equipos serios fijan objetivos sobre el p99, no sobre promedios: domar los peores casos es lo que hace que un producto se sienta rápido de forma fiable.

Premature Optimization — la raíz de todos los males

Reforzar todas las paredes de una casa contra un terremoto que quizá nunca llegue, antes de que nadie se haya mudado — un esfuerzo enorme gastado en un problema que aún no tienes.

La famosa frase de Donald Knuth — «la optimización prematura es la raíz de todos los males» — advierte contra optimizar antes de saber qué necesita hacerlo, o si algo lo necesita.

Optimizar código que no es lento, o que ni siquiera se ejecuta mucho, no compra nada y cuesta bastante: complejidad, errores y tiempo robado a lo que importa. La mayor parte del código no necesita ser rápido; necesita ser correcto y claro. El trabajo de velocidad es para las partes que la medición demuestra que son calientes (hot).

Correct → Clear → Fast — primero correcto y claro, rápido donde cuenta

Escribes la receta para que cualquiera pueda seguirla, y solo agilizas el único paso que haces cien veces al día — no todos los pasos, solo el caliente.

El orden es: hazlo correcto, hazlo claro, y hazlo rápido solo donde la medición muestra que importa.

El código claro es más fácil de optimizar más tarde precisamente porque puedes entenderlo; el código «rápido» enredado es difícil de arreglar cuando el verdadero bottleneck aparece en otro sitio. Optimizar la velocidad casi siempre cuesta legibilidad, así que gastas ese coste solo donde compra una ganancia real y medida — y mantienes simple todo lo demás.

Performance by Design — pero no ignores el rendimiento en el diseño

No se hace un cobertizo a prueba de terremotos, pero tampoco se construye un rascacielos sobre arena — algunas decisiones son baratas de acertar al principio y ruinosas de arreglar al final.

La advertencia no es «nunca pienses en el rendimiento». Elegir un algoritmo O(n²) donde uno O(n) era igual de fácil, o una estructura que no escalará, es un error de diseño que pagarás caro después.

El equilibrio: no hagas microoptimizaciones pronto, pero tampoco tomes decisiones de arquitectura que sean lentas por diseño y caras de deshacer. Acierta barato la forma general desde el principio; optimiza los detalles solo cuando la medición lo exija.

Optimization Loop — mide, arregla el bottleneck, repite

Un mecánico diagnostica con instrumentos, arregla la única pieza que falla y vuelve a probar — nunca cambia piezas al azar esperando que el ruido desaparezca.

El método es simple y disciplinado: mide para encontrar el bottleneck, arregla esa única cosa, vuelve a medir para confirmar y para revelar el siguiente bottleneck, y para cuando sea lo bastante rápido.

Cada pasada apunta al coste dominante actual e ignora todo lo demás. Este bucle mantiene el trabajo de rendimiento honesto y eficiente — siempre sabes que trabajas en lo que de verdad importa, y siempre sabes si ayudaste.

Performance Target — fija un objetivo y para

Aíslas la casa hasta que está lo bastante caliente y paras — no sigues añadiendo aislante para siempre, más allá del punto en que alguien lo note.

El rendimiento no tiene un final natural — siempre puedes hacer algo un poco más rápido. Así que fija un performance target («páginas por debajo de 300 ms en p99») y para cuando lo alcances.

Sin una meta, la optimización se convierte en un pozo de tiempo interminable con rendimientos decrecientes, y se cuela complejidad por ganancias que nadie nota. Saber qué significa «lo bastante rápido» — para tus usuarios, para tu caso de uso — es lo que te permite hacer exactamente el trabajo de rendimiento justo y luego ir a construir otra cosa.

Cómo encaja todo

Toda la ruta en un solo mapa: dónde empiezas, por qué estaciones pasas y dónde te bajas.

Los conceptos forman una sola imagen. El Profiling encuentra el bottleneck; la meta — latency o throughput — te dice qué arreglar. El bottleneck suele curarse con uno de cuatro clásicos: un mejor algoritmo, menos viajes de ida y vuelta, una caché o hacer menos. Luego vuelves a medir, por percentiles, contra un objetivo, y paras. Y la optimización prematura es lo que pasa cuando te saltas la medición.