Explícame cómo analizarías la complejidad temporal y espacial de un trozo de código.

Averigua cómo crece el tiempo de ejecución según crece la entrada, y luego descarta constantes y términos de orden inferior. Lee la estructura del código: los bloques secuenciales se suman, los bucles anidados se multiplican y las llamadas recursivas siguen la recurrencia. El espacio es la memoria extra que reservas más allá de la entrada, incluida la pila de llamadas. Enuncia el peor caso por defecto y menciona el caso medio aparte si difieren de forma significativa.

Empiezo nombrando n, porque la mitad de la confusión en estas conversaciones viene de que dos personas están midiendo cosas distintas. Después leo el código de forma estructural. Los bloques secuenciales se suman, así que gana el más grande; los bucles anidados se multiplican; una llamada recursiva se convierte en una recurrencia que puedo expandir o reconocer. Para el espacio cuento todo lo que reservo más allá de la entrada, y siempre incluyo la pila de llamadas, que es la parte que la gente olvida con la recursión. Un ejemplo concreto: tenía una función que parecía lineal porque era un bucle sobre una lista de pedidos, pero dentro llamábamos a un helper que buscaba un registro por id en una lista. Esa búsqueda era lineal, así que el coste real era cuadrático, y solo se notó cuando un cliente llegó a unos cuarenta mil pedidos. Cambiamos la lista por un diccionario indexado por id y el endpoint pasó de unos nueve segundos a menos de doscientos milisegundos. Así que mi regla es mirar dentro de cada llamada, no solo los bucles que veo.