Analyse Codeflash : 118 bogues de performance détectés dans deux PR rédigés avec Claude Code

Analyse des performances du code généré par IA

Codeflash a utilisé son propre outil d'optimisation pour analyser deux demandes de fusion écrites avec Claude Code. Les fonctionnalités analysées étaient la prise en charge du langage Java (52 000 lignes réparties entre analyseurs, extracteurs de contexte, instrumentation, exécuteurs de tests, transformateurs d'assertions) et la prise en charge du framework React (24 000 lignes couvrant la découverte de composants, le profilage, le benchmarking et le remplacement de code).

Principales découvertes

Rien que dans ces deux demandes de fusion, Codeflash a identifié 118 fonctions dont les performances étaient nettement inférieures au nécessaire. Il ne s'agissait pas de cas marginaux — c'étaient des fonctions situées dans le chemin critique de leur optimiseur, exécutées à chaque tâche d'optimisation pour chaque utilisateur.

Schémas d'inefficacité

• Algorithmes catastrophiquement inefficaces : Une fonction d'extraction de type dans le module de contexte Java était 446 fois plus lente que nécessaire, implémentée avec une analyse de chaîne naïve au lieu d'une extraction basée sur tree-sitter. Un localisateur de fonctions d'aide était 74 fois plus lent pour des raisons similaires.
• Calculs redondants : Les fonctions réanalysaient des données déjà analysées, retraversaient des arbres déjà parcourus, reconstruisaient des chaînes caractère par caractère. Un constructeur d'appels cibles d'assertion était 19 fois plus lent en raison du recalcul des conversions d'octets source à chaque invocation au lieu de les mettre en cache. Un utilitaire d'insertion d'import dans la demande de fusion React était 36 fois plus lent en raison de traversées d'arbres redondantes.
• Absence de mise en cache : Les fonctions appelées à plusieurs reprises avec les mêmes entrées calculaient les résultats à partir de zéro à chaque fois. Un extracteur de définition de type dans la demande de fusion React était 16 fois plus lent sans mémorisation des résultats intermédiaires, et un vérificateur d'export était 9 fois plus lent pour la même raison.
• Structures de données sous-optimales : Des listes là où des ensembles auraient dû être utilisés, des recherches linéaires là où des recherches par hachage auraient fonctionné, des concaténations de chaînes dans des boucles au lieu de jointures. Un analyseur d'équilibrage d'accolades était 3 fois plus lent en raison de choix de structures de données inefficaces.

Exemple concret : amélioration de performance de 19x

Claude Code a écrit cette fonction pour convertir les décalages d'octets en positions de caractères :

# Appelée pour chaque nœud AST trouvé dans le fichier
start_char = len(content_bytes[:start_byte].decode("utf8"))
end_char = len(content_bytes[:end_byte].decode("utf8"))

Codeflash l'a remplacée par :

# Construit une table de recherche une fois, puis recherche binaire pour chaque nœud
from bisect import bisect_right
cum_bytes = [0]
for ch in source.decode("utf8"):
    cum_bytes.append(cum_bytes[-1] + len(ch.encode("utf8")))
start_char = bisect_right(cum_bytes, start_byte) - 1
end_char = bisect_right(cum_bytes, end_byte) - 1

Le code original décode l'intégralité du préfixe d'octets depuis le début du fichier à chaque appel — O(n) par recherche. Pour un fichier avec des centaines de nœuds AST, cela signifie redécoder les mêmes octets des centaines de fois. La version optimisée construit une table de recherche une fois et utilise la recherche binaire — O(n) une fois, puis O(log n) par recherche.

L'article souligne qu'il ne s'agit pas de savoir s'il faut utiliser des agents de codage IA (ils recommandent de les utiliser), mais de ce qui arrive au code après l'avoir fait. Ces problèmes de performance représentent une nouvelle catégorie de dette technique que les agents IA introduisent systématiquement en se concentrant sur la justesse et la lisibilité plutôt que sur l'optimisation des performances.