Expliquez-moi comment vous analyseriez la complexité en temps et en espace d'un bout de code.

Déterminez comment le temps d'exécution croît quand l'entrée croît, puis laissez tomber les constantes et les termes d'ordre inférieur. Lisez la structure du code : les blocs séquentiels s'additionnent, les boucles imbriquées se multiplient, et les appels récursifs suivent la récurrence. L'espace, c'est la mémoire supplémentaire que vous allouez au-delà de l'entrée, pile d'appels comprise. Énoncez le pire cas par défaut, et signalez le cas moyen séparément s'ils diffèrent vraiment.

Je commence par nommer n, parce que la moitié de la confusion dans ces conversations vient de deux personnes qui mesurent des choses différentes. Ensuite je lis le code structurellement. Les blocs séquentiels s'additionnent, donc le plus gros l'emporte ; les boucles imbriquées se multiplient ; un appel récursif devient une récurrence que je peux développer ou reconnaître. Pour l'espace, je compte tout ce que j'alloue au-delà de l'entrée, et j'inclus toujours la pile d'appels, la partie que les gens oublient avec la récursion. Un exemple concret : j'avais une fonction qui semblait linéaire parce que c'était une boucle sur une liste de commandes, mais dedans on appelait un utilitaire qui cherchait un enregistrement par id dans une liste. Cette recherche était linéaire, donc le vrai coût était quadratique, et ça n'est apparu que quand un client a atteint environ quarante mille commandes. On a remplacé la liste par un dictionnaire indexé par id et l'endpoint est passé d'environ neuf secondes à moins de deux cents millisecondes. Ma règle, c'est donc de regarder dans chaque appel, pas seulement dans les boucles visibles.